Smarty

[cwsaylor]

I have been hunting around to see if anybody has subclassed Smarty in the following way. So far I haven't turned up anything.

The idea is to have a main.tpl and then assign content.tpl in the php page instead of including header.tpl and footer.tpl inside of content.tpl. My goal was to not have to include the header and footer on every single template page. I'm not sure if the designers of Smarty really intended for it to be used this way. I would love to hear peoples comments/drawbacks on this.

The subclass Page.class.php looks like this:

[boots]

It is neither new nor dumb

I do believe that I have seen this style in articles before and anyways, I use an extended version of this for some projects--well, one project in particular I talked about it earlier today, but what the heck, since I like this approach, here we go again! I especially like this approach when the abstraction pattern is continued to the point where ALL of the layout is controlled by data objects (in my case, data objects nest and each one defines properties like stylesheet, template, etc.). The big difference in my approach (to the one you state) is that I don't do a thing with Smarty until my data objects are completely processed (also meaning that my entire layout is built). At that point I do a single assign of the data object to a generic template which interprets the layout, calling the appropriate templates for each nested data object. This way, anyone of my data objects can alter any other object at any time in the production process.

The problem with this approach: without a descent design and rigid application of standards, this can blow-up on you as your project expands--more abstract code = more gotchas. You will also likely want to build some integrated editing tools as the abstraction can get a little hard to keep track of. I have an online editor that knows simple things like standard paths, related file types, standard data object interfaces, etc. and puts these types of things together on the editing page for easy reference. In other words, this is typically a bigger programming / project task than more traditional approaches.

On the other hand, it essentially allows you to treat your layout as a big piece of nested data before it even gets sent to Smarty and it allows you to completely remove any notion of application logic from your templates. For large projects, the additional management infrastructure this enables is a godsend.

I hope others comment on this topic as I don't have time to give a more detailed exposition (at least I won't until sometime in mid to late July).

[cwsaylor]

The one thing I don't like about this approach is that I'm assigning the page title from the php page instead of from the template page. This makes template writers have to access the php code. I can't see any way of getting the page title from content.tpl back up to page.tpl without storing it in a database or a config file and then having the Page class lookup the page title.

[boots]

Yes, that is a big issue and the first time I really tried using Smarty I came up with a solution that was gawdawfully complicated. I think one solution even went so far as to write temporary config files.

My present solution is to do an end-run around the problem: I have an object hierarchy established prior to starting Smarty, so process the objects (perhaps looking for a title?) and pass it back up the line. I actually do this at object (node) creation so as to avoid a big tree process just prior to starting Smarty.

However, this is a relatively isolated problem -- in many (if not most) important cases, this is NOT something you have to deal with or worry about.