Savant: Why Plugins?

A good question from the Savant-Talk list today. The quote is from the questioner, and the remainder is my response (almost verbatim from the list).

But could You PLS explain me shortly the main idea of plugins? I mean I can not understand that there is a need to create for example any html form fields by php… I still see the idea of templates as separation of business logic from display logic. From my point of view such example form fields shoud be still in template but not generated by php. So maybe such ones should be provided quite so as a templates or something like that. Only the values should come to them.

Well my wonders goes farther – why to use ANY php or savant function INSIDE template…(?)

First off, use of plugins is not required, of course, so if you don’t like them you don’t need to use them. This is kind of a weak argument, I know, because the code for plugin support is there whether you like it or not — in Savant3 this will end up being about 30 lines (with comments it’s about 50 lines), which I think is very small for the power you can get from them.

But second, and more importantly, they are convenient time-savers. I completely agree with you when you say you “see the idea of templates as separation of business logic from display logic.” To that, I say: a plugin is just an encapsulated, reusable portion of display logic. It gets tiresome to write forms by hand all the time. Instead of *having* to write a select box by looping through options passed in as an assigned variable, and mixing the PHP echo code with the literal HTML, you can use one line in the template to call the ‘form’ plugin and generate a select box with correct items pre-selected for you.

One argument against plugins is that they are not a necessary component of a template engine; if you want convenience methods, you can instantiate your own output objects and assign them to the template, or write them as global functions, or call them as static class methods. This is a perfectly valid argument. However, to my mind, that kind of thing is a “pattern” of development, and will end up looking nearly the same across all implementations. All that Savant does is take the common aspects of that pattern and codify them for common use so that different developers can collaborate easily and effectively using the same higher-level tool set.

This is not a comprehensive defense of plugins, but I hope this brief essay begins to show why plugins can be useful and worthwhile in a template system.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

3 thoughts on “Savant: Why Plugins?

  1. Its a common misconception in my view that templates should not contain logic. They should just not contain business logic but instead be only concerned with display logic. Some people prever to keep the display logic inside yet another layer, but I find this approach to be too inefficient both performance and also for the designer (since he needs to chunk up the html code into little snippets).

    Obiviously something like alternating row colors in a table does not belong in the business logic. I also think that a template should be free to generate plain text, html, xml, pdf, excel or even images. All of this is display logic and belongs into the template.

    On the plugins idea the only problem I see with how people use plugins is that they stick few lines of code into separate files. I find this a somewhat annoying style and it probably also doesnt help performance either. Especially with a bytecode cache.

  2. Even if it is quite convenient to autoload Savant plugins based on filenames, you can also put all commonly used plugins in one file that gets included in every script. In my experience, this yields better performance and avoids dozens of includes with 10 lines of code each (especially if you are generating every bit of repetitive HTML thru plugins, as I like to do).

    I agree with Lukas concerning the separation of application logic and display logic. The savant object gets the raw data from the application (strings, arrays, objects…), and the template generates all (HTML or other) output, “hardcoded” or via savant plugins. This way it is quite easy to decide (for me at least) what goes where.

  3. Heiner, you said “you can also put all commonly used plugins in one file that gets included in every script”. This is perfectly valid; in fact, the autoload portion of Savant only tries to load the class if it does not already exist. So if you want to preload a set of plugins, or keep them all in one file and load that file, it’s perfectly acceptable practice.

Leave a Reply

Your email address will not be published. Required fields are marked *