RE: [SMARTY-DEV] Quick Question

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_pathheader.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