Re: Templates: how to get that HTML outta my templates!

One solution that I'm leaning on more and more is XML/XSLT. Your business logic generates XML and the presentation transformation to HTML is handled with XSLT. That means that instead of your application worrying about how to lay out a menu, you just build something like this: <menu type="main"> <menuitem> <name>Discussion</name> <url>/discussion.php</url> </menuitem> </menu> Your layout people can create different XSLT files that all use this XML to build pages. They would need to learn a bit of XSLT, but it's not really very difficult for this kind of simple substitution. <xsl:for-each select="/menu[type='main']/menuitem"> <xsl:element name="a"> <xsl:attribute name="href"><xsl:value-of select="/url"/></xsl:attribute> <xsl:value-of select="/name"/> </xsl:element> <br/> </xsl:for-each> This works particularly well if the business logic isn't written yet. The layout folks can use a sample XML file to build their XSLT and, as long as you generate XML that matches the sample, you can meet in the middle. "Rita Mikusch" <MIKUSCH@ica.bc.ca> wrote in message news:10C5C8152BD5D31181AC006008AD5F416889B0@NEWCA2... > Sorry for bringing this topic up yet again, but I'm having a real problem > with the details of implementing a templates system. I'm read all the > tutorials, articles, emails etc, but was hoping others on this list with the > same problems could share how they solved them. > > Now I understand the basic logic of a template system: separate the client > side code (html, javascript) from the PHP. That way I can write my PHP > modules then hand them off to the HTML programmers and designers to > implement in their webpages. > > Two ways to do this (that I can think of at the moment) would be to use PHP > functions <?php create_main_menu(); ?>, or to use include files <?php > include("main_menu.php3"); ?>. > > The problem is that I use PHP throughout my webpages and find it very > difficult to elegantly separate the HTML and PHP code. I use it for main > menus, sub menus, titles, page listings, article listings, next-page links, > random image generation, etc etc. > > As an example lets look at a menu. There are a lot of ways that menu could > be designed. The designer could have a little icon in front of each menu > item, or behind each menu item, or have a special background colour, or > special font colour, etc etc etc. The list is endless. The PHP code is going > to have to loop through that menu array, display each menu item, then add > the appropriate html for that menu item. How the heck do I separate the HTML > and PHP here? One option I thought of was to create a PHP function with the > HTML design components making up the function's arguments. Ie, argument one > would be the name of the mouse-over image in front of each menu item, > argument two would be it's height, argument three would be it's width. etc > etc ad infinitem. What a mess! You would end up with an insane number of > arguements. > > How do users of template systems deal with these problems? > > I work in a very small tech department (there are four of us, and I do all > the PHP coding) and found it was easiest in the long run to just divide up > the webpages into components and turn these components into include files. > For example, the main menu component, sub menu component, page list > component, page contents component, etc etc. Each component is a full > autonomous table that can can easily pop into the basic table structure of a > website. (I've found that dividing up one table into two or more files is > just confusing!) > > Others in the department who are designing a webpage to which I'll be adding > PHP components just use sample data for menus, page content, etc. I take a > look at it then, make sure the design is "database-driven content friendly", > then add the php bits. > > When you use template driven websites, do you find there are certain > projects they work better for. Are they more appropriate for larger websites > with larger groups of people working on them? > > I'd really be interested in other people's solutions and experiences! > > Thanks, Rita.