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