|
|
Posted by Robert Cummings on 04/30/05 05:17
On Fri, 2005-04-29 at 21:09, Mattias Thorslund wrote:
> Rasmus Lerdorf wrote:
>
> > Mattias Thorslund wrote:
> >
> >> Who says PHP itself is a template engine? I think nobody.
> >
> >
> > I do.
> >
> > It comes down to whether you want the delineation between the template
> > and the business logic enforced by the system or not. PHP is a
> > general-purpose templating system that does not enforce this
> > delineation.
> That explanation is sensible enough.
>
>
> [skipping ahead a little]
>
> > The approach I tend to point people at is something I have been
> > calling a Template API. That is, when you build your application, you
> > create a template api to go along with it. In essence you are
> > creating a templating system for each application you write.
I think a problem here is when you decide to blend two projects that
started out separately. With a templating system (some anyways :) you
can just redefine the main layout for each page being merged into the
larger project in a single centralized location. The approach described
above would appear to require in depth modification of the application's
"template API".
> For many projects, I think the approach you describe in the example
> (below) is appropriate. One nice thing is that output can begin before
> the whole page has been nearly processed. I don't know if many other
> templating solutions can do that.
Personally I find having the output ALWAYS begin after all business
logic has completed to be a better choice, that way upon error (a
catchable error) you can redirect the user to an info page that might
state the page is temporarily unaccessible.
> To me, it looks like it would be hard to keep the functions that are
> called by the template to a reasonable format or number, at least in a
> larger project. If it's a template that is to be used by many kinds of
> pages, there would be either a large number of functions, or there would
> be generic functions that need to do different things based on the
> situation.
I don't think that templates have a dependency between the number of
pages using the template and an increase in the number of functions. In
fact depending on the template, and the template engine, you can have
500 pages using the template and not a single function call. Including
the elimination of include() and include_once() calls since if the
template engine compiles to PHP it can do the includes at compile time
rather than punting to PHP to do at run-time.
> Of course, the functions could become methods of a "page" object. Then,
> it gets easy to create specialized subclasses of page objects which can
> respond differently to the same generic method call. Sounds more
> attractive the more I think about it :-)
So every time you want a small difference you subclass the main page
object. Seems a lot of work and overhead for something small. What
happens when you want to share functionality from one project in another
without recoding or copying it?
I personally prefer the modularization of custom functionality into
loadable compiler modules. I find this especially convenient when an XML
or XML-like template system is used that allows namespaces. Then you can
just include already created functionality via module includes at
compile time, and incur no overhead at run-time. Not to mention you get
to skip past the whole sub-classing nightmare, although there's nothing
to stop you from sub-classing a compiler module :) But at least it's
more portable and re-usable. Overhead is still incurred for
transformation on dynamic content, but even still if you are
transforming dynamic content via the template engine you at least
minimize the amount of work needing to be done at run-time.
> Then again, if I need a big object to handle the business logic (and
> dynamic presentation logic) because my template approach is sequential,
> it might be a toss-up compared to using sequential business logic and a
> small template object.
>
>
> > For example, I describe a simple such system here:
> >
> > http://talks.php.net/show/mtladv05/20
> >
> > To me, this is a perfectly good template (from the slide):
> >
> > <?php
> > start_poll(1);
> > $os = array("FreeBSD","Linux","OSX","Windows","Other");
> > ?>
> > <p class="purpose">
> > Please answer a couple of questions for us.
> > </p>
> >
> > <p class="question">
> > 1. What is your name?
> > </p>
> > <?php text_answer('name',64)?>
> >
> > <p class="question">
> > 2. Which operating systems do you use on a daily basis?
> > </p>
> > <?php select_any_of($os)?>
> >
> > <p class="question">
> > 3. Which operating system do you prefer?
> > </p>
> > <?php select_one_of($os)?>
> >
> > <?php end_poll(); ?>
> >
> > The end_poll() call could be eliminated as well to make it slightly
> > cleaner, but otherwise this is straight-forward with no mixing of
> > business-logic and content.
This works, but now what happens when your client/boss requests that the
operating system choice not be a multi-select list but rather checkboxes
and those check boxes should be 3 columns wide. The convenient
select_any_of() function is no longer usable and while I know you can
still use PHP as the template language, it surely doesn't look as neat
as the above. Now add validation error messages, javascript events, and
other stuff that is usually required in a real life situation. The
source starts to get difficult to read and maintain as you switch in and
out of PHP, HTML, and Javascript :)
> > My main issue with general-purpose templating systems is that they
> > always end up inventing a new language.
Not always. An XML style templating language is making use of an
existing language which is much closer to the format used by content
developers than PHP. And even if you are a coder, using XML tags in HTML
content rather than switching in and out of PHP tags makes the source
much easier to grok while providing an advantage that PHP still doesn't
have, and from what I've read recently, won't be adding anytime soon...
named and optional parameters.
Contrast:
<?php displayNews( 'Latest News', 'cbc', null, '#eeeeff' ); ?>
Versus:
<?php displayNews( array( 'title'=>'Latest News', 'source'=>'cbc',
'bgcolour'=>'#eeeeff' ) ); ?>
Versus:
<aProject:news title="Latest News" source="cbc" bgcolour="#eeeeff"/>
At a glance the first PHP version requires intimate knowledge of the
function parameters (what each is and the order). Additionally because I
wanted to override the background colour but not the number of paging
entries, I had to include the extra "null" parameter to inform the
function to skip past it.
The second PHP version is functionaly as good as the XML version, but
let's admit it, it's not nearly as clean and coherent.
> Except the class described in the article I was talking about. It uses
> PHP as the template language. It's a big reason why I find it attractive.
>
> [skipping discussion on Smarty]
>
> > As far as I am concerned you shouldn't be dealing with any sort of
> > objects from a template to begin with.
>
>
> This does place some demands on the business logic.
>
> > There should be nothing but simple variables and straight function
> > calls from a template, but this is a religious issue that people will
> > never agree on. Hence PHP's neutral approach where the exact
> > templating delienation is left up to the users.
I think there should be nothing but simple variables and function calls
(or at least the equivalents for any given template system) but
additionally I believe foreach and if constructs to also be appropriate
to act upon the simple variables and function calls to avoid the need to
move display logic back into the business logic.
> No doubt, people will continue to argue over it for a long time to
> come. I try not to be religious about it, I simply want to know as many
> sides of the issue as possible.
IMHO the advocacy of a templating system depends on the project. I
wouldn't generally use one for a small 2 to 5 page project, but once I
start getting into projects with more than 10 pages, and especially
projects with 100s of pages, I'd be hard pressed to accept a straight
PHP implementation.
Ultimately I think this debate is similar to the braces style debate.
Some people just prefer one style over the other and there's not really
a right or wrong position, just a general warm fuzzy feeling that you're
doing things the way you best see fit :)
Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Navigation:
[Reply to this message]
|