The Need to Edit Content
First efforts to separate presentation from content were crude and required HTML snippets stored as text and edited in my favorite text editor. Although this was better than each page being complete and separate entities, It was at best a kludge. What I really wanted was an editor that would allow me to enter the content directly and an application that would parse and display the content as intended without having to keep track of the different tag orders in the different files.
I was in the process of building a PERL based script to manage different SQL databases and database servers. This was more an exercise for my personal use than an attempt to build something marketable. As the thing began to take shape I realized much of what I was doing had already by done by development teams and the amount of work needed would have kept me busy for a good long while. I also realized how simple it would be to use some of my work to help me manage websites.
PHP had already gained wide-spread acceptance as the website development tool of choice. Although comfortable with PERL it was evident to me that this support for PHP meant I had to switch scripting languages. There were some serious misconceptions about PERL scripts vs PHP scripts and search engines. I'm really not sure why PHP began to overshadow PERL in the marketplace but I started coding in PHP. The transition from coding in PERL to PHP wasn't difficult at all. The silver catalog gave some first hand experience at parsing and formatting data stored in a DB.
I was in the process of building a PERL based script to manage different SQL databases and database servers. This was more an exercise for my personal use than an attempt to build something marketable. As the thing began to take shape I realized much of what I was doing had already by done by development teams and the amount of work needed would have kept me busy for a good long while. I also realized how simple it would be to use some of my work to help me manage websites.
PHP had already gained wide-spread acceptance as the website development tool of choice. Although comfortable with PERL it was evident to me that this support for PHP meant I had to switch scripting languages. There were some serious misconceptions about PERL scripts vs PHP scripts and search engines. I'm really not sure why PHP began to overshadow PERL in the marketplace but I started coding in PHP. The transition from coding in PERL to PHP wasn't difficult at all. The silver catalog gave some first hand experience at parsing and formatting data stored in a DB.
Content Managers Were Available
Not only were there content managers out there but some pretty cool WYSIWYG editors existed. At the core of most CMS type applications is some sort of WYSIWYG editor. I have used a few, I have yet to find one that didn't load a page up with extraneous, useless tags and in-line style. With some of the more advanced editors these things are kept to a minimum an some even put out well-formed XML. I have yet to use a WYSIWYG editor that didn't require the at least a half hour of cleaning up the html entered.
It's taken some time, but I think I've got a framework/CMS application that works quite well. The page generation is section driven and allows for any number of features, such as panoramic images, various gallery types, the addition of links to pages, scripts or named regions. One feature I like best is the ability to build a module, upload it to a repository on the server and then load it into a dedicated page or simply append it to a page. The actual editing is NOT done in a WYSIWYG editor and any in-line formatting or links are done via my own small rendition of something similar to BB code.
It's taken some time, but I think I've got a framework/CMS application that works quite well. The page generation is section driven and allows for any number of features, such as panoramic images, various gallery types, the addition of links to pages, scripts or named regions. One feature I like best is the ability to build a module, upload it to a repository on the server and then load it into a dedicated page or simply append it to a page. The actual editing is NOT done in a WYSIWYG editor and any in-line formatting or links are done via my own small rendition of something similar to BB code.
This is not some tool where a neophyte can just build pages using some kind of template. Although templates can be built for it I guess the person creating a page must know xHTML, CSS, and some basic PHP. Some so-called Web Developers have had a look and realizing that actual coding is required cannot understand how to get started. Once a site is set up adding content or functionality is quite simple.
Where most CMS editors give you an editor and you are required to do much of the formatting, I thought it would be much better to setup a design and devise a method where the look and feel remains consistent. Flexibility is important also. So. after dividing up the page vertically I set about slicing it horizontally. I wanted to present the page as it is to be seen on the site but I didn't want to set up a WYSIWYG editor and all the problems I see inherent in those systems. The first effort was crude and would actually display a column section and a link to a form in a separate page. Nasty stuf. But the idea was sound.
Where most CMS editors give you an editor and you are required to do much of the formatting, I thought it would be much better to setup a design and devise a method where the look and feel remains consistent. Flexibility is important also. So. after dividing up the page vertically I set about slicing it horizontally. I wanted to present the page as it is to be seen on the site but I didn't want to set up a WYSIWYG editor and all the problems I see inherent in those systems. The first effort was crude and would actually display a column section and a link to a form in a separate page. Nasty stuf. But the idea was sound.
