RE: [Phplib-users] template extensions
Brought to you by:
nhruby,
richardarcher
From: Rob H. <rob...@ws...> - 2003-01-15 02:46:04
|
I uses the module extension along with a minor tweak to the template class. The module extension is attached. The tweak was that there is an inconsistant use of finish within the template class itself between get and print I believe (it's been a while). It is attached also. Rob Hutton Web Safe www.wsafe.com ********************************************************************** Introducing Symantec Client Security - Integrated Anti-Virus, Firewall, and Intrusion Detection for the Client. Learn more: http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 > -----Original Message----- > From: php...@li... > [mailto:php...@li...]On Behalf Of Aric Caley > Sent: Tuesday, January 14, 2003 5:39 PM > To: php...@li... > Subject: Re: [Phplib-users] template extensions > > > > ----- Original Message ----- > From: "Layne Weathers" <la...@of...> > To: <php...@li...> > Sent: Tuesday, January 14, 2003 1:24 PM > Subject: RE: [Phplib-users] template extensions > > > > Before I reply to any particular statements, it appears to me that some > > people on this list might be dealing with some internal project issues. > > There have been several comments about not trusting the programmers and > not > > knowing what the final outcome of the project is going to be. You cannot > > expect to solve your development problems, whether from communication or > > incompetence in your team, by a clever software hack. If you cannot > > coordinate programmers and graphic designers it is time to evaluate your > > culture/environment and personnel. > > No argument there. :) > > > Quoth Evan Hughes: > > > I'll be the first to admit that this isn't a huge saving. > > > All it gives us is: > > > a) Faster runtime (there's no risk of unused variables > > > being created) > > > > This simply is not true. The current template implementation has the > > following basic steps: > > > > 1. set variables in an array > > 2. preg_replace the variable names with the variable content > > 3. if unknowns is not set to "keep", replace all variable matches with > empty > > string or comment > > > > The proposed change would add the following steps: > > > > 3. find each remaining variable (or function or whatever) match > > 4. loop through the result set > > a. find associated function, if it exists > > b. run function and replace in template with output > > > > The problem is that the current implementation doesn't have to look at > each > > undefined variable - your implementation would. > > I could be wrong, but looking at the template class you find a > method called > finish() which in fact looks at every variable (well, the > preg_replace does, > anyway) that's left and decides what to do with them. You could > easily add > a new type "callback" to the existing "keep, remove, comment" and > have that > one do a preg_replace_callback(). > > That would be very generic and optional, adding no real overhead > if its not > used. > > Then he could make a subclass of template, define his callback function to > take the variable name and include a file/run a function based on that, > returning the data to be used in the template. > > > > As a side note: Consider the implications of (b) and (c) > > > from above. If we > > > take the whole variable backing thing to an extreme, we can > > > move all of the > > > dynamically generated content out of php scripts and stick > > > them into files. > > > This means we don't need any php between the templates and > > > the outside world. > > > If we use .htaccess to prevent download of .tpl files, and > > > catch requests for > > > them with an error_document handler (which would evaluate the > > > named template), > > > we can essentially provide an interface where we're just > > > serving raw templates. > > > > > > Stop! What problem are you trying to solve here? Now you're > talking about > > content caching, which is completely different from variable layouts. > > > > Also, you've mentioned in a couple messages that you would like > to remove > > PHP from the public site. If that is your true gain, you cannot rely on > the > > Template class - it's PHP! > > That one doesnt make sense to me either.. :) > > > > > Layne Weathers > > Ifworld Inc. > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: Take your first step towards giving > > your online business a competitive advantage. Test-drive a Thawte SSL > > certificate - our easy online guide will show you how. Click here to get > > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > > _______________________________________________ > > Phplib-users mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phplib-users > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Take your first step towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > > |