Thread: [Phplib-users] template extensions
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Mike G. <mi...@op...> - 2003-01-14 02:41:54
|
Hello, A colleague of mine asked me about extending phplib templates so that it would be possible to pass functions and variables back through the template variables. I didn't think that this was possible with the current version of the code, but wanted to bring forward the idea here to see if someone had already done this and if there was interest within the community. In reasearching this I noticed that there were a number of other extensions to phplib here: http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1 And I wanted to see if there was any movement to build these extensions into the phplib code base. Evan's thought was that it would be really, really nice there were hooks for calling functions right in the templates, allowing our pages to look something like: article.tpl: ----------------- {header} <body> <table> <tr> <td><!-- leftbar--> {Poll()}<br> {MailingListSignup()}<br> {RSSFeeds()}<br> </td> <td><!-- main content --> {Article($ArticleId)} </td> <td><!-- Right bar --> ... ----------------- All of those functions (stuff in curlies with '()'s after the name) would resolve to a php function that would be called (or maybe a file that would be evaluated as php, or something =). That would really clean up the content files, and provide really, really nice modularization. An instance that occured to me is that it seems silly to have have multiple template variables for something like {BANNER1} ... (BANNERn), when you could have a {BANNER(1)} tag to pass along that info to a function. Mike -- Mike Gifford <mi...@op...> OpenConcept Consulting http://www.openconcept.ca |
|
From: Evan H. <hu...@bi...> - 2003-01-14 18:49:16
|
Howdy,
I'm the colleague that Mike mentioned. The remainder of this email is
a more in-depth description of what Mike had mentioned.
Dr Tarique Sani wrote:
> On 13 Jan 2003, Mike Gifford wrote:
> > <td><!-- main content -->
> > {Article($ArticleId)}
> one question
> How will the $ArticleId be passed to the template?
'ArticleId' would be used as a key into the globals array.
The germ of my idea doesn't rest on variable passing (although that could be
a Good Thing, it isn't the basis of my idea). What I'm really interested in
is backing variables with functions -- which would allow static pages to
reference content that is generated dynamically. This would allow the creation
of templates that require no intervention from PHP to render content.
Consider the following situation:
I'm building a site where I want all pages to follow a certain format, and
contain a number of elements that are repeated between pages. However,
different elements will appear on different pages (even though at coding time,
I'm not sure what will appear where). Say that I want my dynamic elements to
be:
Poll - Dynamically generated poll
RDF - RDF listing of the site's content
Calendar - A calendar of events
LoggedIn - A listing of who is logged in
News - A listing of news items
I know that these are necessary when I'm writing the code that will generate
the site, but I'm not sure when or where they will be used (I'm not in control
of final appearance/layout, someone else is).
Using the current architecture I would be forced to define all of these
elements before evaluating the templates, even if they aren't used in the
page.
In a function backed variable architecture, I would define a directory that
would contain a listing of renderers that would produce output for a given
variable names. So, for this example, I would have a directory that would
contain a set of files (functions/Poll.php, functions/RDF.php,
functions/Calendar.php, etc). When the parser in template.inc tried to link a
variable reference that it doesn't know about, it would check this directory -
if there is a file that matches the name of the variable, it would be
evaluated and its output linked into that variable.
The value of backing variables with functions should be apparent outside of
this example: the one-file-per-variable constraint on content forces
encapsulation of functionality into a single file that would have a
well-defined interface.
e
|
|
From: Evan H. <hu...@bi...> - 2003-01-14 19:28:47
|
Andrew Crawford wrote:
...
> Maybe I'm not understanding something. That just seems backwards to
> me. Normally, the PHP file is being evaluated and pulls formatting
> information from the template. So, now, the template would be evaluated
> and pull code from another file? Why?
To abstract the presentation away from the code. Currently, if I want to add
a dynamic block of html (one that's backed by code instead of static data from
a file), I have to:
1. write a bunch of code to create the dynamic content
2. modify the php script that will be including the template (to add the
set_var())
3. modify the template to include the named variable
In a situation where variables are backed by functions, step two can be
dropped. This lessens the coupling between the php script in 2 and the template
in 3.
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)
b) Enforced encapsulation of variable definition into separate files. Notice
that this really encourages reuse.
c) Greater decoupling of templates and their defining code.
But it comes at virtually no cost. The only change to the API that I see
would be a "set_backing_dir(path)" which would set the path to the directory
that contains the files that would back the variables.
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.
> Instead of putting those functions in the template, couldn't you just put
> template variables in the template and have the PHP code filling in the
> template perform the functions for those variables?
You could. What Mike and I are suggesting is essentially just a lazy linker:
instead of exhaustively defining all possible variables before the script
is run (or worse, sculpting code that will conform to the templates),
simply move the resolution of variables to a just-in-time model where they're
defined as needed.
> Or, if there is some reason I am missing to want to do this, why use
> templates at all? Why not just use straight PHP and use <?php include
> your_function.php; ?> or <?php your_function(n); ?> in place of your
> curly-bracketed functions?
Because that mixes presentation with logic. As soon as it's in vanilla php,
we lose the ability to use templates (unless we're calling out to other files,
etc).
--
Evan Hughes
OpenConcept Consulting (openconcept.ca)
|
|
From: Aric C. <gre...@pe...> - 2003-01-14 19:54:43
|
Seems like this could be done very genericaly. Simply change the template class to have a callback option for unknown variables in the template. Then you could easily have a subclassed template object that defines that callback method to do what you are describing. You could also do other things, like for instance use it to look up language translations automaticaly for variables that are just going to be strings, instead of doing a big set_var() with your own "get_string()" or whatever for each variable. ----- Original Message ----- From: "Evan Hughes" <hu...@bi...> To: <php...@li...> Sent: Tuesday, January 14, 2003 11:27 AM Subject: [Phplib-users] template extensions > Andrew Crawford wrote: > ... > > Maybe I'm not understanding something. That just seems backwards to > > me. Normally, the PHP file is being evaluated and pulls formatting > > information from the template. So, now, the template would be evaluated > > and pull code from another file? Why? > > To abstract the presentation away from the code. Currently, if I want to add > a dynamic block of html (one that's backed by code instead of static data from > a file), I have to: > 1. write a bunch of code to create the dynamic content > 2. modify the php script that will be including the template (to add the > set_var()) > 3. modify the template to include the named variable > > In a situation where variables are backed by functions, step two can be > dropped. This lessens the coupling between the php script in 2 and the template > in 3. > > 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) > b) Enforced encapsulation of variable definition into separate files. Notice > that this really encourages reuse. > c) Greater decoupling of templates and their defining code. > > But it comes at virtually no cost. The only change to the API that I see > would be a "set_backing_dir(path)" which would set the path to the directory > that contains the files that would back the variables. > > 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. > > > > Instead of putting those functions in the template, couldn't you just put > > template variables in the template and have the PHP code filling in the > > template perform the functions for those variables? > > You could. What Mike and I are suggesting is essentially just a lazy linker: > instead of exhaustively defining all possible variables before the script > is run (or worse, sculpting code that will conform to the templates), > simply move the resolution of variables to a just-in-time model where they're > defined as needed. > > > Or, if there is some reason I am missing to want to do this, why use > > templates at all? Why not just use straight PHP and use <?php include > > your_function.php; ?> or <?php your_function(n); ?> in place of your > > curly-bracketed functions? > > Because that mixes presentation with logic. As soon as it's in vanilla php, > we lose the ability to use templates (unless we're calling out to other files, > etc). > > -- > Evan Hughes > OpenConcept Consulting (openconcept.ca) > > > > ------------------------------------------------------- > 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 > |
|
From: Evan H. <hu...@bi...> - 2003-01-14 19:51:05
|
Richard Archer wrote: > The philosophy of the template class is to separate the data > presentation from the application logic. template.inc does this, and > does it very well (and with good performance into the bargain). The approach that Mike and I are suggesting improves that separation, without any negative impact on performance (I'm speaking from a theoretical perspective: I haven't implemented this, so I can't be certain). Currently there is a tight coupling between code and templates because variables corresponding to dynamic content must be defined explicitly in php. This means that there is either a hand crafted php script sitting in front of every template, or there are more variables being defined than are necessary. The proposed approach would sever that connection. Instead of a hand-crafted script sitting in front of each template defining variables (in a coder-dependant manner that may or may not encourage reuse), there would be a standard location where dynamically generated content would live. As a template is evaluated, and reference to that content are detected, it would be imported and generated. Notice that lovingly hand-crafted scripts (made by italian monks to the highest standards, using a secret process handed down from their celebate forefathers) are no longer necessary. All templates can be treated the same. Notice that all dynamically generated content in a site is now put into a single location and forced to be encapsulated (there are arguments against wholesale encapsulation, but that's where php's 'include' statement comes into play). > Once you start adding scripting to a template class, where do you stop. These would not be scripting components. They would be references to files to run and include (a la server-side-includes, php's include, and a plethora of inclusion tools). There would be no logic stored in the templates: no control structures, no variables, no operators, no expressions. All we are suggesting is late binding. Instead of doing all of the variable/value binding up front (before the template is evaluated), we would allow it to be done later in the run cycle (on demand). > You finish up re-implementing PHP within PHP. And you open up a whole > lot of security concerns which designers shouldn't need to worry about. Again: no. There would be no difference between this mechanism and the existing include mechanism. > And you kill your performance. Not according to the architecture we have suggested. -- Evan Hughes OpenConcept Consulting (openconcept.ca) |
|
From: Aric C. <gre...@pe...> - 2003-01-14 19:59:54
|
> > The proposed approach would sever that connection. Instead of a hand-crafted > script sitting in front of each template defining variables (in a > coder-dependant manner that may or may not encourage reuse), there would be a > standard location where dynamically generated content would live. As a > template is evaluated, and reference to that content are detected, it would > be imported and generated. > > Notice that lovingly hand-crafted scripts (made by italian monks to the > highest standards, using a secret process handed down from their celebate > forefathers) are no longer necessary. All templates can be treated the same. > > Notice that all dynamically generated content in a site is now put into a > single location and forced to be encapsulated (there are arguments against > wholesale encapsulation, but that's where php's 'include' statement comes into > play). Another aspect of this is that if the designer wants something that hasnt been coded yet, he can just put some dummy html data into a file where the function would be, and the programmer can come along later and turn it into proper php code. > -- > Evan Hughes > OpenConcept Consulting (openconcept.ca) > > > > ------------------------------------------------------- > 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 > |
|
From: Aric C. <gre...@pe...> - 2003-01-14 02:59:37
|
It seems to go against the general idea of templates: to separate code from
presentation.
That said, this seems like a really cool idea.
It could make the whole code base merely an API that is called from the
templates, thus letting the templates determine the whole structure of a
page, whereas now the code decides what template goes where, which can be
really limiting to the guy doing the site layout.
It would also be nice for the templates to be able to use this to tell the
code what to do in certain cases. For instance, what if the template has a
4 by n grid. But the designer wants it changed to, say 6 wide. Currently
you'd probably have a nested set of blocks (one for horizontal, one for
vertical) and the code would determine how many wide to go, so the
programmer would have to go in and change that. With this you could just
have something like this:
{setmatrix(4)}
<!-- BEGIN matrix -->
<img src="block.gif">
<!-- END matrix -->
And the code would know what to do.
----- Original Message -----
From: "Mike Gifford" <mi...@op...>
To: "phplib mailing list" <php...@li...>
Cc: "Evan Hughes" <eh...@ju...>
Sent: Monday, January 13, 2003 6:42 PM
Subject: [Phplib-users] template extensions
> Hello,
>
> A colleague of mine asked me about extending phplib templates so that it
> would be possible to pass functions and variables back through the
> template variables.
>
> I didn't think that this was possible with the current version of the
> code, but wanted to bring forward the idea here to see if someone had
> already done this and if there was interest within the community.
>
> In reasearching this I noticed that there were a number of other
> extensions to phplib here:
>
http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1
>
> And I wanted to see if there was any movement to build these extensions
> into the phplib code base.
>
>
> Evan's thought was that it would be really, really nice there were hooks
> for calling functions right in the templates, allowing our pages to look
> something like:
>
> article.tpl:
> -----------------
> {header}
> <body>
> <table>
> <tr>
> <td><!-- leftbar-->
> {Poll()}<br>
> {MailingListSignup()}<br>
> {RSSFeeds()}<br>
> </td>
> <td><!-- main content -->
> {Article($ArticleId)}
> </td>
> <td><!-- Right bar -->
> ...
> -----------------
>
> All of those functions (stuff in curlies with '()'s after the name)
> would resolve to a php function that would be called (or maybe a file
> that would be evaluated as php, or something =). That would really clean
> up the content files, and provide really, really nice modularization.
>
> An instance that occured to me is that it seems silly to have have
> multiple template variables for something like {BANNER1} ... (BANNERn),
> when you could have a {BANNER(1)} tag to pass along that info to a
> function.
>
> Mike
> --
> Mike Gifford <mi...@op...>
> OpenConcept Consulting http://www.openconcept.ca
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
|
|
From: Dr T. S. <ta...@sa...> - 2003-01-14 03:12:22
|
On 13 Jan 2003, Mike Gifford wrote:
> <td><!-- main content -->
> {Article($ArticleId)}
one question
How will the $ArticleId be passed to the template?
Tarique
--
===================================================================
PHP Applications for E-Biz: http://www.sanisoft.com -o)
/\\
Indian PHP User Group: http://groups.yahoo.com/group/in-phpug _\_v
===================================================================
|
|
From: Richard A. <rh...@ju...> - 2003-01-14 03:59:43
|
At 21:42 -0500 13/1/03, Mike Gifford wrote: >In reasearching this I noticed that there were a number of other >extensions to phplib here: >http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1 That web site says: Please login to access. Personally I have no intention of signing up for more spam just to see if the classes are worth including in PHPLIB. Feel free to download them and post them to PHPLIB's patches tracker on SourceForge, where I (and other developers) will look at them and merge them if I think they are nifty enough :) >Evan's thought was that it would be really, really nice there were hooks >for calling functions right in the templates, allowing our pages to look >something like: There are a couple of patches to template.inc in the Patches tracker. I have no intention of merging either caching or functions into the mainline template class, simply because I don't think they belong there. The philosophy of the template class is to separate the data presentation from the application logic. template.inc does this, and does it very well (and with good performance into the bargain). Once you start adding scripting to a template class, where do you stop. You finish up re-implementing PHP within PHP. And you open up a whole lot of security concerns which designers shouldn't need to worry about. And you kill your performance. I see three options for someone who wants this level of scripting: 1. drop the template class and use PHP (which is after all just a very advanced template engine with scripting capabilities). Add a "<? include("my_functions.inc"); ?>" to the top of the file, and the rest of it looks like a template with <?, ?> as the template delimiters. 2. use one of the other scriptable template engines (template.inc is a standalone component of PHPLIB and can easily be replaced with say smarty). 3. patch your template.inc with one of the patches from the SF tracker. This is getting harder to do as time goes by because the patches are becoming out of sync with the mainline template class. If you merge the patch into the current template.inc, please repost a new diff to the patches tracker :) ...R. |
|
From: Andrew C. <An...@Ev...> - 2003-01-14 06:41:05
|
At 09:42 PM 1/13/2003 -0500, Mike Gifford wrote:
>Evan's thought was that it would be really, really nice there were hooks
>for calling functions right in the templates, allowing our pages to look
>something like:
>All of those functions (stuff in curlies with '()'s after the name)
>would resolve to a php function that would be called (or maybe a file
>that would be evaluated as php, or something =). That would really clean
>up the content files, and provide really, really nice modularization.
Maybe I'm not understanding something. That just seems backwards to
me. Normally, the PHP file is being evaluated and pulls formatting
information from the template. So, now, the template would be evaluated
and pull code from another file? Why?
Instead of putting those functions in the template, couldn't you just put
template variables in the template and have the PHP code filling in the
template perform the functions for those variables?
Or, if there is some reason I am missing to want to do this, why use
templates at all? Why not just use straight PHP and use <?php include
your_function.php; ?> or <?php your_function(n); ?> in place of your
curly-bracketed functions?
At 06:59 PM 1/13/2003 -0800, Aric Caley wrote:
>It seems to go against the general idea of templates: to separate code from
>presentation.
It seems that way to me, too.
>It would also be nice for the templates to be able to use this to tell the
>code what to do in certain cases. For instance, what if the template has a
>4 by n grid. But the designer wants it changed to, say 6 wide. Currently
>you'd probably have a nested set of blocks (one for horizontal, one for
>vertical) and the code would determine how many wide to go, so the
>programmer would have to go in and change that. With this you could just
>have something like this:
>
>{setmatrix(4)}
><!-- BEGIN matrix -->
><img src="block.gif">
><!-- END matrix -->
>
>And the code would know what to do.
... or, you could code that as a variable in a configuration file or the
header section of your PHP file that fills in the template. Then, the PHP
file could determine what to do with that information. Strangely enough,
I've done exactly that with some of the stuff I have developed.
For example, an image gallery thumbnail page has a configuration file that
has variables like thumbs_num_rows and thumbs_num_columns. The designer
can choose the numbers after the equal signs without even as much brain
power as required to understand the {setmatrix(4)} syntax. You can even
put a more detailed comment right before the settings for the unusually
obtuse designer. The PHP code then iterates appropriately when filling in
the template. It works great.
Andrew Crawford
An...@Ev...
|
|
From: Aric C. <gre...@pe...> - 2003-01-14 18:41:46
|
> At 06:59 PM 1/13/2003 -0800, Aric Caley wrote:
> >It seems to go against the general idea of templates: to separate code
from
> >presentation.
>
> It seems that way to me, too.
>
> >It would also be nice for the templates to be able to use this to tell
the
> >code what to do in certain cases. For instance, what if the template has
a
> >4 by n grid. But the designer wants it changed to, say 6 wide.
Currently
> >you'd probably have a nested set of blocks (one for horizontal, one for
> >vertical) and the code would determine how many wide to go, so the
> >programmer would have to go in and change that. With this you could just
> >have something like this:
> >
> >{setmatrix(4)}
> ><!-- BEGIN matrix -->
> ><img src="block.gif">
> ><!-- END matrix -->
> >
> >And the code would know what to do.
>
> ... or, you could code that as a variable in a configuration file or the
> header section of your PHP file that fills in the template. Then, the PHP
> file could determine what to do with that information. Strangely enough,
> I've done exactly that with some of the stuff I have developed.
>
> For example, an image gallery thumbnail page has a configuration file that
> has variables like thumbs_num_rows and thumbs_num_columns. The designer
> can choose the numbers after the equal signs without even as much brain
> power as required to understand the {setmatrix(4)} syntax. You can even
> put a more detailed comment right before the settings for the unusually
> obtuse designer. The PHP code then iterates appropriately when filling in
> the template. It works great.
And that's what I currently do.
The more interesting aspect of this idea is that the designer could not only
create the cosmetics but could more easily rearrange the whole structure of
the site through the template, where normaly this would require moving
around blocks of code.
Then again, this could be achieved with the current template system and just
using more clever code.
>
> Andrew Crawford
> An...@Ev...
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
|
Thanks for helping keep SourceForge clean.
X