RE: [SMARTY-DEV] Integrating Smarty with Content Management Syste m, questions and design issues (long posting)

It strikes me that you could probably implement modifiers on function calls by taking a modifier list as a parameter to the function call. The function gets a reference to the $smarty object, so, inside your function you could parse the modifier list, and access the loaded modifiers on the smarty object, calling the modifier functions yourself on the output of your function before you print the output. this might look like this in the template: {myfunc param1="foo" param2="bar" func_modifiers="mymod|mymod2"} the implementation of myfunc might look like this (pseudo-code, sorry): function smarty_function_myfunc( $params, &$smarty ) { $output = <do whatever myfunc does>; $modifiers = _parse_modifiers_list($params['func_modifiers']); for( reset($modifiers); $modname = current($modifiers); next($modifiers) ) { list($func_name, $tpl_file, $tpl_line) = $smarty->_plugins['modifier'][$modname]; $output = $func_name($output); } } Of course, there is error handling needed, and you'd need to figure out some way of dealing with the modifier parameters during the parsing....it's just pseudo code. It is kind of kludgy way to do it, but it would probably work. A better solution would be to modify the smarty compiler (and runtime engine) to treat variables and functions (everything that can produce a string value) in the same way, thus allowing modifiers to be applied directly to function calls as a matter of language syntax, without kludgy hacks. -Lee > -----Original Message----- > From: Matthias Pigulla [mailto:mp@webfactory.de] > Sent: Wednesday, November 20, 2002 4:21 PM > To: 'Monte Ohrt' > Cc: 'smarty-dev@lists.php.net' > Subject: AW: [SMARTY-DEV] Integrating Smarty with Content Management > Syste m, questions and design issues (long posting) > > > > Hi Monte, > hi everyone else, > > > If you want one call to display() so your cache files are all > > together, > > you could create an init.tpl file that loops through the > templates you > > want displayed like so: > > > > $this->draw(array('head.tpl','main.tpl','foot.tpl')); > > > > {foreach from=$templates item=curr_tpl} > > {include file=$curr_tpl} > > {/foreach} > > This would require me to know the subparts in advance, at > least my engine > would have to pay attention to that. By now, the engine just > has to load the > template class, make a $template from it and call > $template->draw(). The > entire process of subdividing the template into subparts is > beyond the scope > of the engine, that is, can be done in a project specific way > by modifying > project specific files. > > Maybe I misunderstood your approach? > > However, this issue is not so important as the following one :) > > > > > > <h1>{cmscontent field="title"}</h1> > > > <p>{cmscontent field="bodytext"}</p> > > > What does cmscontent function do, just retrieve your > variable? Can you > > assign the content to the template, then access them like > > {$cmscontent.title} {$cmscontent.bodytext|mymod} ? > > Basically, I have some "page" objects. These represent all > the elements that > make up the content of a specific page. The custom function > encapsulates API > calls on these objects that retrieve page content. > > These API calls are quite expensive, some of them require > five oder even > more database queries. Besides that, prefetching all elements > of a page > would be a memory waste as I will probably only need a > fraction of them. > > Most important, however, is the fact that I do not know in > advance which > "page"s will get involved, so I cannot assign the values to > template vars in > advance. This is closely related to the block function issue > below, but lets > say you want to build a navigation bar; you would make an API > call to get an > iterator for page objects. You then would iterate it and in > each iteration > retrieve some content, lets say the document title, with it. > This is what > the construct > > <ul>{iteratenavigation rootid="123" mode="preorder" > var="navelement"} > <li>{cmscontent var=$navelement field="text"}</li> > {/iteratenavigation} > > is supposed to say. Last but not least, I need to track which of the > "fields" on a certain page object were requested at all. This > is related to > some cache expiry issues, so I cannot just expose the values > as variables > but instead need real method calls to register their use. > > > > What was the design motivation for this? > > Not sure, Andrei? > > What I presumably need lies between a compiler function for > opening as well > as closing tags (would work, but might be too low-level) and > the as-is block > functions. You should be able to repeat the _execution_ (not only the > contents) of a block, which is not possible with the current > implementation. > I'm not sure whether you really need to insert any kind of > loop constructs > at compile time, or if we could get along with function calls at the > beginning and the end of the block during runtime. > > Can you assess what block functions are found "in the wild", > or in which way > they depend on being called at runtime? I am sure it would gain new > possibilities if we changed that behaviour, so, would it > limit us in some > other aspects? > > [I shall say that I do not expect any changes to the Smarty > engine just to > make it fit my needs :) I could have my "personal branch" to > incorporate all > this; however, it would simplify maintenance for us >:) and > maybe we could > share some interesting extensions with everyone else.] > > Btw, I just saw that "lets-implement-a-new-compiler-class" > thread on the > archives which was posted one or two weeks ago? Any decisions on that? > > Best regards, > Matthias > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >