[prev in list] [next in list] [prev in thread] [next in thread] 

List:       smarty-dev
Subject:    RE: [SMARTY-DEV] Quick Question
From:       boots <jayboots () yahoo ! com>
Date:       2003-03-27 4:30:11
[Download RAW message or body]

I agree that messing with the internals is not the best idea. I had
already started to write a modifier (similar to what you suggested),
but I didn't like it because I happen to use vars instead of hardcoded
template file names and that implies syntax not any more pleasant than
what I suggested previously. Your idea did get me to thinking that
instead of a modifier, a compiler function might be more appropriate to
reduce the overhead of filesystem io during execution. I imagine that
the template path is NOT implemented as a lookup array (like modules)
just to reduce the number of path lookups that are required during
execution and I find this to be a very reasonable design decision.

The way I use smarty, I setup all data prior to invoking display. That
way I generalize the templates and data structures and can control
sub-template selection through pre-arranged data structures--before
firing smarty up. As a result, all required paths are calculated prior
to invoking display. I find this to be a more sound approach (for my
needs) because it truly seperates the data handling (and layout
control) from the template design. In fact, once I create a data graph,
I can cache it seperately from the caching of the templates or render
it in a completely different way by choosing a different starting
template--without recompiling either my data or the templates. In other
words, I don't think that directory calculations should be handled in
template. Also, I tend to agree that there is a valid reason to try to
stick to out-of-the-box Smarty style syntax--especially for basic
features like template loading :).

When I really think about it, I wonder why I didn't think of resources
right from the start. In this case, a "theme" resource handler can be
created allowing templates to be included as in:

{include file="theme:foo.tpl"}

The "theme" resource would be trivial to code and could be extended
with little effort (and complete template transparency) when the time
comes to redesign your theme storage structure or reimplement it in
another container, such as a db, soap service, etc. It occurs to me
that this is exactly the type of situation that resources are supposed
to handle!

When I first used Smarty, I thought that multiple template paths were a
missing feature. Now I understand that they aren't. There's a good
reason that {include file="foo.tpl"} should only point to ONE place in
the file system. Otherwise, it makes understanding the template logic
confusing because it is never immediately obvious WHERE the included
template will come from (and therefore, which to debug!). Using a
resource makes it obvious that "theme:foo.tpl" does not point to a
specific file in the filesystem, even to developers not familiar with
the application.

That's 4c.

xo boots

--- Monte Ohrt <monte@ispi.net> wrote:
> Would it be possible to write your own custom function to do this?
> Overriding internal Smarty functions sounds like an invitation to
> future
> maintenance and quirky bug issues.
> 
> Something like this:
> 
> {resolve_path file="foo.tpl" assign="tpl_path"}
> {include file=$tpl_path}
> 
> Or maybe even a modifier:
> 
> {include file="foo.tpl"|resolve_path}
> 
> my 2 c.
> Monte
> 
> On Wed, 2003-03-26 at 14:27, luis wrote:
> > It's an idea but I really don't want to change all the templates
> and I
> > can't ensure that everybody involved in the development remembers
> to use
> > include preppending the variable.
> > I did override the fetch and _smarty_include methods and it works.
> I
> > would have preferred to override only one function but two is good
> > enough :-)
> > Now a theme can override zero, one or many templates just putting
> the
> > new templates in templates/$theme_name. That's exactly what I
> wanted.
> > 
> > BTW: Thanks to Monte, Messju and the people that wrote for this
> thread.
> > 
> > Luis
> > 
> > 
> > -----Original Message-----
> > From: boots [mailto:jayboots@yahoo.com] 
> > Sent: Wednesday, March 26, 2003 5:22 PM
> > To: smarty-dev@lists.php.net
> > Subject: RE: [SMARTY-DEV] Quick Question
> > 
> > luis:
> > ------------------
> > Well, I can answer myself, no. If I have
> > 
> > display('foo.tpl');
> > 
> > and foo.tpl {includes file='header.tpl'}
> > 
> > I need to look BOTH for foo.tpl and header.tpl in templates/$user
> > and if they are not found there in templates/ If I redefine fetch
> then
> > foo.tpl can be checked but fetch is not called for the included
> > header.tpl template. Ideas?
> > ------------------
> > 
> > Well, to add just a little bit more to this thread... instead of
> > overriding smarty's internal functions, you might be able to do the
> > following.
> > 
> > 1) extend Smarty as per Monte's suggestion, overriding the default
> > smarty->Display. In the new Display code, also add a smarty assign
> > statement such as:
> > 
> > $this->assign('_tpl_path', $tpl_path);
> > 
> > where $tpl_path is either blank ("") or the user path to the file
> (ie.
> > $user.'/' as appropriate)
> > 
> > In your templates, you would include files like this:
> > 
> > {include file=$`_tpl_path`header.tpl}
> > 
> > This definately works, though, unfortunately, you have to change
> your
> > template code slightly. The nice thing, is that this prevents
> Smarty
> > from having to search paths on every invocation of a template.
> > 
> > It may not be a bad idea to create a custom function in this case.
> > Currently, {include} does NOT work the way you want it to and the
> way
> > you want it to work DEFINATELY is not in line with the current
> design.
> > Therefore, a custom function seems appropriate. Then again, I like
> the
> > assign approach :)
> > 
> > just my 2c.
> > 
> > xo boots


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]