Re: Real world usage of IT [template] class?

Hi, Thanks for the enlightenment, Dietrich. One question, though: by doing setVariable on individual pages, doesn't that mean you have to duplicate code on every page that needs a particular placeholder to be parsed? Another side effect of this is that a designer would not be able to add a placeholder to another page from another one without a programmer's intervention. (For example, the {DISPLAY_USERNAME} placeholder on index.php could not just be added to contact.php without a developer first adding a setVariable call in contact.php to parse that "new" placeholder.) Originally, I had wanted to put all parsing into a class and then modularize the setVariable calls so that a designer could add any placeholder from any page to any page without a developer's intervention. But the problem I am coming across is that I can't think of a reasonable way to pass information to the class for the "modules". For example, I would have one module (e.g., displayFormErrors()) which would be invoked by having the {SHOW_FORM_ERRORS} placeholder on a page template. If there are errors, the error messages (contained in an array that's prepared by the PHP script that does the form processing) would be passed to displayFormErrors() in the layout class (which does the appropriate setVariable calls). It would be relatively simple to create an include file for the displayFormErrors() functionality which is included into the main layout class whenever the {SHOW_FORM_ERRORS} placeholder is present, but I don't know how I would be able to pass the actual form errors to that included class in such a way that another module with a completely different format (e.g., showNewsItems()) would work in the same way. Any tips? Do you think I'm approaching this in the wrong way? Are "global" placeholders as I am proposing in this sense not generally desirable to begin with? -f On 04.08.2002 3:24 pm, "Dietrich Ayala" <dietrich@ganx4.com> wrote: > here's what i do, in a nutshell: > > i have a global template, a page template, and (X) block templates. > > global template: has global css and javascript and metatags, and placeholders > for adding css, javascript, metatags, title, etc > > page template: has layout for a specific page (or set of pages), and > placeholders for whatever blocks i'll be loading into it. > > block templates: an example would be a block of HTML to print out a single > news item > > in my PHP script: > 1. load the global template, set vars > 2. load the page template, set vars > 3. load the block template, query the db for some news items, loop through the > recordset, parsing the block for each. > > the result of all of this is basically that the designer has a block of html > (the news block template) and some vars in it that they > can place anywhere in that block of html, without ever having to look at the > PHP script. > they don't have to think about if/then, looping, anything. all they have to > think about is "where should i put the {title}, and > should i make it bold?" > >> -----Original Message----- >> From: derek fong [mailto:pear@subtitled.com] >> Sent: Monday, April 08, 2002 8:47 AM >> To: Dietrich Ayala; PEAR General >> Subject: Re: [PEAR] Real world usage of IT [template] class? >> >> >> Hi, >> >> I'm basically just trying to brainstorm ideas on how to properly structure >> the code for templates at a low level. I think the page you pointed me at >> is a good basis. But for me, my concerns are more along the lines of what >> actually goes into the PHP script that calls the template logic? It seems >> to me that if all template parsing is done by a centralized function (since >> reproducing it in every single PHP script seems redundant since it's all >> doing the same thing anyway, i.e., load the template file, parse it, display >> it), it's theoretically possible that nothing needs to be put into the PHP >> script itself except for the actual static content of the page. And this >> also poses some conceptual problems for me. If I have a global, site-wide >> template file structured like this: >> >> <html> >> <body> >> {CONTENT} >> </body> >> </html> >> >> Then doesn't that mean that in order to change the content portion (which >> would be straight HTML), a designer would have to go into the actual PHP >> script? Doesn't that negate a major advantage of using templates in the >> first place, in that designers should never need to see a line of PHP code? >> Or does that mean that {CONTENT} should be replaced by a file block which >> contains the HTML content for the page, and that that file should be placed >> in a separate repository for designers to manipulate? So you'd basically >> have a directory structure like so: >> >> /templates >> site.tmpl.php (contains global navigation and look-and-feel for whole >> site) >> /includes >> parse_template.inc.php (functions parse the site template for each page >> in public_html) >> /content >> index.tmpl.php (contains static HTML page content) >> page1.tmpl.php >> /public_html >> index.php ("dummy" scripts since they don't really do anything) >> page1.php >> >> My apologies if what I'm asking isn't clear, but I'm still trying to get my >> head around some of these concepts and how to make them work in the best >> possible way to separate the code from design, while at the same time making >> sure that it's not too "heavy" and easy to extend the system later if >> necessary. >> >> -f >> >> >> On 04.05.2002 5:58 pm, "Dietrich Ayala" <dietrich@ganx4.com> wrote: >> >>> i'm not sure what your goal is, but i've done some work similar to what you >>> describe in #1. i have some writing about this here: >>> http://dietrich.ganx4.com/site_projects.php, under the >>> "PHP, PEAR and MVC" >>> header. >>> >>> what i'd like to do is use the template introspection methods in ITX for >>> "bidirectional templating". EG: map blocknames to table >>> names or functions, and have block-variable names map to table fields, or >>> hash >>> keys in a hash returned from a function. >>> then, the designer chooses from a library of predetermined blocks, each w/ >>> predetermined variables. >>> >>> to get this really MVC, i use a controller object that loads the template >>> object, introspects and loads the appropriate model >>> (business logic object), and merges it's output into the view (template >>> object). >>> >>> d. >>> >>>> -----Original Message----- >>>> From: derek fong [mailto:pear@subtitled.com] >>>> Sent: Friday, April 05, 2002 11:32 AM >>>> To: Dietrich Ayala; PEAR General >>>> Subject: Re: [PEAR] Real world usage of IT [template] class? >>>> >>>> >>>> Hi Dietrich, >>>> >>>> Thanks for pointing me in the right direction! Do you have any small >>>> samples of how this should all be put together? The approaches I have been >>>> considering are: >>>> >>>> 1. Making an auto_prepend file that automatically looks for "standard" >>>> placeholders on all pages, even though many of those placeholders may not >>>> necessarily exist on a given page. The advantage to this is that a >>>> designer >>>> would not have to ask for a given functionality to be added to a PHP >>>> script, >>>> but would be able to choose from a library of standard ones that could be >>>> included on any page without a PHP programmer's intervention. I'm not >>>> sure >>>> if this is efficient or would slow things down, though. >>>> >>>> 2. Each page would parse only expected placeholder tags. The advantage is >>>> that we know what we're looking for and only replace those placeholders >>>> that >>>> are expected to be present on that page, so it should be fast. The >>>> disadvantage is that if a designer wants to add new functionality (which >>>> may >>>> already exist elsewhere on the site, but not on the current page), a PHP >>>> developer needs to get involved to add that functionality to that >>>> particular >>>> page (and remove any "dead" ones that are no longer used). >>>> >>>> 3. I think I saw a method of retrieving the names of all placeholders... >>>> maybe go through each "standard and global" placeholder tag with their >>>> expected content, then parse the remaining "unknowns" on a page by page >>>> basis? Similar to #1, but this way, we don't do a global search for every >>>> known, standard placeholder. >>>> >>>> I am sure there are other strategies for this. Can you or anyone else >>>> provide some tips on how to approach the design? >>>> >>>> Thanks! >>>> >>>> -f >>>> >>>> >>>> On 04.04.2002 1:10 pm, "Dietrich Ayala" <dietrich@ganx4.com> wrote: >>>> >>>>> If you use ITX (which extends IT), you have access to a method >>>>> addBlockFile(), >>>>> which does what you need. >>>>> >>>>> api docs are here: >>>>> >>>>> http://www.ulf-wendel.de/docs/itx/index2.html >>>>> >>>>> btw, I use IT(X) for all of my client's projects (albeit a modified >>>>> version). >>>>> It's my fav template solution, in spite of all the >>>>> crap it gets from people on this list. Use the tool that's right for the >>>>> job, >>>>> eh? >>>>> >>>>> Dietrich >>>>> >>>>>> -----Original Message----- >>>>>> From: derek fong [mailto:pear@subtitled.com] >>>>>> Sent: Thursday, April 04, 2002 6:52 AM >>>>>> To: derek fong; PEAR General >>>>>> Subject: Re: [PEAR] Real world usage of IT [template] class? >>>>>> >>>>>> >>>>>> Hmmm... so should I take it that nobody really uses PEAR's IT class? >>>>>> Too >>>>>> bad, it looks like it could be useful... :( >>>>>> >>>>>> Anyway, if anyone does use it, maybe you can help me out with this one. >>>>>> What is the proper way to include a file into an existing template which >>>>>> has >>>>>> its own placeholders? I think I'm supposed to use the get_file() >>>>>> method, >>>>>> but I can never seem to parse the placeholders in the file that's >>>>>> included. >>>>>> >>>>>> $tpl = new IntegratedTemplate("./"); >>>>>> $tpl->loadTemplatefile("template.tmpl", false, false); >>>>>> >>>>>> // parse DMZ helper on right side of the page >>>>>> $dmz_content = $tpl->getFile("template2.tmpl"); >>>>>> $tpl->setVariable("DMZ", $dmz_content); >>>>>> >>>>>> $tpl->setCurrentBlock("dmz"); >>>>>> $tpl->setVariable("DMZ_LIST", "-&nbsp;<a >>>>>> href=\"test.php\">Name</a> >>>>>> (#)<br>"); >>>>>> $tpl->parseCurrentBlock("dmz"); >>>>>> >>>>>> $tpl->setCurrentBlock("main_body"); >>>>>> $tpl->setVariable("USERNAME", "Derek Fong"); >>>>>> $tpl->setCurrentBlock("main_body"); >>>>>> ... >>>>>> >>>>>> What am I missing? >>>>>> >>>>>> -f >>>>>> >>>>>> >>>>>> >>>>>> On 03.30.2002 10:42 am, "derek fong" <pear@subtitled.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am considering using the IT class for the first time in an upcoming >>>>>>> project. Can anyone give me any pointers on how to most effectively >>>>>>> set >>>>>>> everything up? Any caveats? >>>>>>> >>>>>>> I have followed the docs on >>>>>>> http://pear.php.net/ and while it seems >>>>>>> pretty >>>>>>> straightforward, it would be nice to see a real-world example of how >>>>>>> everything comes together. >>>>>>> >>>>>>> Finally, as the first of what will probably become many questions, what >>>>>>> is >>>>>>> the best way of setting up form logic so that on first view, all the >>>>>>> text >>>>>>> on >>>>>>> the page is black, but if there are any errors on the submission, the >>>>>>> same >>>>>>> page is returned, but with the relevant fields in red text? The only >>>>>>> way >>>>>>> I >>>>>>> can see how to do that would be to actually embed the style in the code >>>>>>> that >>>>>>> replaces the placeholder. Am I correct? Is it considered >>>>>>> "acceptable" >>>>>>> to >>>>>>> embed minimal display elements in the code (such as <span class=... >>>>>>> or >>>>>>> <font >>>>>>> color=...) even though that's supposed to be all contained within >>>>>>> the >>>>>>> template file? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -f >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> PEAR General Mailing List (http://pear.php.net/) >>>>>> To unsubscribe, visit: >>>>>> http://www.php.net/unsub.php >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >