i’m not really that crazy about the current design of the main ocliw.com pages, but i am digging the technology used. for a long while i’ve been debating how to manage some of the front end issues for ocliw.com, in particular how i handle the CMS stuff for the site.

super duper geeky details of how i finally got to where i did after the jump. seriously, only consider going to see more if you REALLY care about PHP4 vs PHP5’s handling on XML parsing. it’s really that dull, otherwise.

i looked into various CMS packages, but most of them seemed like overkill for what i ultimately wanted. well, either overkill or far, far too limiting. my instinct was to have an XML driven site. i was originally thinking about using XML to hold the content for the pages and to use XSLT to transform the XML into HTML.

this in theory sounds great. use industry standards and i should be fine. what i found as i learned XSLT is that it’s a serious pain in the ass. sure, it is very powerful, but one of the things that really irritated me about XSLT is that i find that trying to visualize what the templates do is not nearly as intuitive as standard HTML. in fact, it can become downright confusing. one of the main reasons i thought XSLT was used was because it allowed non-technical people to transform XML easily into HTML. this is not the case.

and my goal really is to use technologies so that non-technical people can easily make cosmetic changes to the templates without the intervention of programmers. also, i wanted to be able to easily visualize the page by looking at the HTML-based code. XSLT just is too abstract in my eyes to make this possible. as such, i threw it out the window pretty quickly.

i really didn’t want to give up with the idea of storing my content in XML, though. i still think that’s great idea, so i started to think about what the best way would be to transform this XML into HTML. since i’m using PHP, there were a few choices i had parsing XML. unfortunately, PHP4 support of XML has been plagued with problems and PHP5 has completely revamped the way it deals with XML. as such, i had a decision to make: how do i want to parse XML.

this was a difficult decision because PHP4 has several options as well as classes that you can use to parse the XML. my preference was not to use any of the PEAR classes or other such libraries to parse XML because i didn’t want the overhead associated with reading the file and parsing it with PHP code. i assumed that one of the built-in ways was faster and potentially less prone to bugs.

due to the lack of a real standard, i decided to abandon PHP4 and opt for PHP5’s parsing of XML. PHP5 has two real big ways to parse XML. parsing the XML as a DOM object or using the SimpleXML interface. if you are only making reads into an XML file, SimpleXML appears to be the easiest way to gain access to the XML data. if you need to make changes to the tree structure or navigate it in a more interesting way, it appears that the DOM method works better. the SimpleXML method requires you to have knowledge about the structure of the XML.

so after doing some investigation, i’ve decided that for my needs, SimpleXML should suffice. once i’ve figured out how to parse the XML, i needed to decide how to transform it to HTML. having thrown out XSLT, this becomes the second step of the process.

enter smarty. i have always loved smarty ever since i started using it a few years ago. what’s beautiful about smarty is that it really is a fully developed templating engine that allows the programmer to truly separate the code from the presentation. this is great because it then allows non-programmers to go into the templates and edit the templates, more or less. depending on how much template logic you use, it is either brain-dead simple or moderately difficult. but it’s a vast improvement compared to the XSLT equivalent.

so PHP5, SimpleXML, and Smarty are the three elements used to drive the ocliw.com site. i haven’t quite made the move to a more sophisticated publishing mechanism because i really do enjoy making web pages and i like to hand code that sort of thing. but this at the very least makes cosmetic changes to the site simpler than before. eventually, i’d like to have some kind of CMS managing the XML files. i would imagine that it would be running off a mySQL database using some kind of DB abstraction layer…perhaps PEAR’s DB classes.

i’ve also been looking at the propel project, but i’m not convinced that it is quite ready for primetime. and i do feel that it is a little overkill for my particular needs at the time.

i’m not totally convinced that this is the best way to manage the rest of the pages, but it’s a start.