Smarty

[atu]

With OOP programming we can write reusable code and we can have a well-structured application api. But there are also limits. In a shared environment as on a server platform it isn’t possible to foresee memory usage. OOP programming, if pushed at its limits, takes more memory in usage and people, who have poor OOP knowledge lose quickly the overview of what is going on. Smarty give us an alternative to a strictly OOP way. Plugin functions are only loaded on demand. So an application, which makes heavy use of plugins, can take lesser memory usage as if the same functionality is included from an OOP api. This means if we use plugins to give live to an application we move the control to the templates.

Here we show a procedure to get data of a document and push it in a template. We assume that the application has a module-based structure. So if a module needs some data, which comes from an other module the example 1 code load first the api of a “doc” module (which can be a huge class) and assign the data to a smarty template variable. The example 2 is a plugin function of the “doc” module. It loads only a small class to get document data.

Examples 1:

[Justin]

in addition to this, there's a good article about diference between pull-mvc and push-mvc patterns. you can read it here.

personally I'm thinking, that combination of both patterns is the best solution.
_________________
http://www.baubas.net

[boots]

atu, this is interesting!

I certainly appreciate the idea for more minimal impact coding The following is simply my perspective after a lot of trials and experimentation as well as experience implementing several sites which are now in production.

I've been humming and hawing over this issue. I'm not sure I entirely buy the plugin approach, at least based on my understanding of the way you have laid it out. My basic premise is that plugins are not intended to (and probably should not be used to) access and implement application logic.

The way I understand your proposal some of the application logic (and structure) is integrated into the template (I am very much against this). If a template can generically access (and instance) your application models, this can lead to some unwanted effects. For example, if two different modules are accessed and manipulated by a template, then the essential outcome is a new process that lies outside of your delivered application.

Another thing: if you are using plugins because they are loaded on demand, then consider this: every template requires data to render (otherwise it is merely static text) meaning that every template you consider will necesarilly make that plugin call -- you aren't saving anything on the actual data calls and you may be overcalling your models (two different templates may require the exact same data).

I don't use an MVC pattern (partially for the very reasons you mention). I do use an object-based pattern which pre-calculates a hierarchy (or graph) of node objects. Each object contains data to display as well as data relating to which template, css, javascript, etc that is to be used to render the data. In this way, the app is responsible for all aspects of the generated data as well as the specification of the "sititching" together (or layering) of the various template chunks. At the application level, I can choose to serialize data and otherwise shortcut the production process where appropriate. I use a fairly light-weight node object and the main burden is the data-persistence layer (which is highly abstracted) and not the actual graph hierarchy. Indeed, the contents of this hierarchy would necessarily have to be duplicated in some form by a plugin based method anyhow as the hierarchy is essentially just the payload data annotated with rendering data (as mentioned earlier).

I like this method as opposed to the plugin method because it leads to very clean development lines in terms of separating project tasks. I also like it better than "pure" MVC approaches because it is somewhat "lighter"--though I don't have hard data on the exact "costs" of this method in terms of resources, I intend to make some measurements on that. My experience tells me that the overhead is minimal (I am always concerned about resource utilization, but not exclusively).

Still, I've been wanting to provide a plugin to allow the templates to at least access the generalized persistance layer so that recordsets can be readily returned (in that case, the nodes would provide the metadata required for the templates to make the calls). It would be dead simple to enable this in my structure, but everytime I think of doing that I start to think about how that means that the templates can acquire arbitrary data (as opposed to easy access to the data I want them to have) and that stops me dead. The job of the template is to render data structures passed to it by the calling application -- and that is all. IMO, anything else breaks the paradigm.

I'm certainly not saying that my approach is the end-all (it can stand many improvements, that I can attest to). One day I would like to see another abstraction or tempalte layer developed which efficiently (and conveniently) encapsulates the hierarchy or application model as data. Perhaps one day.

Anyways, good food for thought and another nice post -- thanks for that!

[atu]

Hi Boots,

[atu]

Hi again,
I forgot to say that the method I use to include data in templates is only on solution between many others. May it isn’t the best one but it works. This method reduces the time between project planning and completion and in many cases I don’t have to write one single php line.

Boots, I can understand your doubts to include application logic in templates. But until today I cant see any solution, which is flexible and easy to handle.

Enjoy the canadian springtime!