|
Wednesday 25 June 2003 9:24:45 am
It think XSLT is one alternative although it has to be used in a certain way (IMO) to translate eZP templates into a PHP script as a "compile time" process, the PHP script being "runtime" (i.e. what gets executed when a user requests a page). I have to confess that where I'm coming from here is ASP.NET, which I've been studying recently to get ideas from that could be applied to PHP ("ASP.NET in a Nutshell" is a pretty good resource). Overall I have to give MS their credit - they've done something very clever with ASP.NET which is invent a template syntax which relates directly to an underlying class library. Even Sun think it's smart an are following suit with Java Server Faces. In terms of a concept, ASP.NET is a template language which is very similar to Mozilla's XUL - it relates to a library of "widgets" which are used to create objects at runtime and render the page although where XUL is for building rich clients, ASP.NET is for web pages. The big thing ASP.NET does is abstract any control structures (loops, if/else etc) out of the template (which makes it possible it possible to use an IDE to "drop and drop" a web page when designing it), as well as providing a bunch of widgets, like a calendar, which make life easy for users. Anyway - more than enough about ASP.NET. Been having some fascinating discussion recently with PHP coders considering how to bring the same thing to PHP. The general conclusion seems to be the way to do this is to have two sets of "components", compile time components and runtime components, then parse the template, with help from the compile time components, into a native PHP script which loads / executes runtime components. The objects that the runtime script instantiates are made available for further "manipulation" by the "controller" code (the specific application code) to do things like allow the runtime components to display different HTML/content if a particular HTTP request is received. Making sense? I've been playing working on a couple of PEAR projects recently that could be the foundations for a parser, PEAR::XML_HTMLSax (a parser for badly formed XML) and one I've recently submitted, XML_SaxFilters, which is yet to be accepted. Reason I'm mentioning these here is I made a crude attempt doing this for an example which may help explain better; The original template begins looking like this; http://code.phppatterns.com/XML_SaxFilters/docs/examples/page_template.tpl.phps Once parsed the output looks like this; http://code.phppatterns.com/XML_SaxFilters/docs/examples/compiled_template.phps The "runtime components" are imaginary and the compiled template is very crude but hopefully it demonstrates the point. The script that parsed this looks like; http://code.phppatterns.com/XML_SaxFilters/docs/examples/template.phps The filters in that script are (poorly abstracted) "compile time" components. This is using SaxFilters, which is only one approach. A badly formed DOM parser might be alot better. For more information on SaxFilters the docs I've written are;
http://code.phppatterns.com/XML_SaxFilters/docs/Readme.phps
http://code.phppatterns.com/XML_SaxFilters/docs/SaxFiltersGuide.phps The complete code is up at; http://www.phppatterns.com/index.php/filemanager/fileview/29/ Apologies if that sounds like self promotion - not intended but simply to share ideas.
|