Beyond The Template Engine

Hi folks,

check this out, I think this is a way to go. Much much better way than 99% of the template engine.

http://www.sitepoint.com/article/beyond-template-engine

M.

So, basically you’re suggesting we treat the template more like a snippet than a chunk, and throw out the ability to easily include snippets and chunks and document variables and other placeholders?

The point of the MODx template system is that it goes through MODx’s parser. Take away that template system, and most of MODx crumbles around it.

What, to you, would be the benefit of this?

And what is the 1% of the template engine that you do like?

I don’t agree with the article idea: when he says "separation of business logic from presentational logic" I mean "separate what thinks from what looks", not "separate what gets the data from what presents the data". If a piece of code thinks about presentating the data, it’s actually doing business logic!

Where is the usefulness of a template engine like the one the author suggest if everyone who works with CMSs can write PHP? They can simply write the code!
A pure-html-designer can? Is that template-engine concept useful for him? Or he will always need someone who knopws PHP to get his objectives?

I think the author, Brian Lozier, has no clear idea of what he’s talking about, and has probably never studied concepts like MVC. He’s struggling with all the chaos of HTML/PHP/CMS without a clue. I know of some "experts" who claim that we do not need anything beyond PHP, because PHP is in itself a templating-engine. This view stands just for the other extreme... both extremes do not contribute anything of value - imho.

I think the model of using a templating language directly, failed when JSP became popular. It was cool, and did help isolate logic from presentation, but it is essentially a new language to learn, and you needed a JSP developer to do anything with it. Need a new page, call the JSP developer. In fact, I’d say early PHP was directly inspired by a lot of things in JSP, just as the more recent PHP releases seem inspired by the J2EE industry in general. And though it is another language to deal with on top of PHP, the whole idea with MODx, IMO, has always been to simplify and modularize content development and presentation by breaking down the content and logic, into loosely-coupled (i.e. independent), re-usable pieces that can be easily extended or customized. And I believe MODx is also lot more than a templating language. It’s a content management framework, with great potential to become a serious web application development and integration framework as well.

Now, the ultimate goal for MODx, in my perspective, is to have the current presentation abstraction layer (as I like to refer to the MODx `templating engine`) working closely with a more robust business logic/data abstraction layer to make creating, managing, using, and most importantly, integrating these pieces, as easy and efficient as possible. IMO, content integration is the biggest part of content management, and something that many of us deal with frequently on larger projects. We need mature forum products, or gallery systems, or blog systems, or a legacy/custom web application, but we want it integrated with our great XHTML/CSS design; and wouldn’t it be great to have one, simple design, development, and integration platform with which to present data from whatever the source of it? That’s my goal at least, and the reason I am involved with MODx, because I think it is the perfect platform from which to achieve this. Otherwise, I think MODx would be attempting to be a little more than it should. That’s why I think the focus of the MODx project should stay on approaches to content presentation, integration, aggregation, and management, from any source; that’s the major strength I see in the tool.

Anyway, as MODx add-on development becomes easier with the continued evolution of the MODx core, and more generic add-on pieces start to fit together in remarkable ways, I think we’ll start to see great improvement in the usability of both the core and add-ons as a result, via higher levels, or layers of UI abstraction (e.g. a form helper class that helps bridge data persistence with UI presentation needs can help a developer create dynamic forms easily in a snippet, and in turn that developer, or a third party, can build a Wizard interface for allowing a non-developer to configure the snippet appropriately). That’s why I think something like what the author is discussing is really not applicable to us, at least not as much as say to Smarty. And in the end, MODx does allow direct PHP templating; it just helps you to better organize and make the most of it.

Admittedly, I’m a lightweight in evaluating such weightier matters, but NOT that lightweight that I can’t weigh in on this.

I agree with paul and opengeek that one of the primary strengths of MODx IS the ability to template with smaller micro-templates as we know them (snippets, chunks, etc.) The sitepoint article (by a programmer with the strong coding skills) shouldn’t even be cited as a model for this market. As the author stated in his article, he’s quite capable of writing his own CMS without the use of templates. To template or NOT is obviously the question a savvy programmer doesn’t NEED to obsess over. It’s my understanding that MODx is being developed for a market of web developers that can’t boast of such skills.

Quote from: eagleshout at Aug 30, 2006, 08:29 PM

It’s my understanding that MODx is being developed for a market of web developers that can’t boast of such skills.

Or at least aimed at the day-to-day maintainance not requiring huge skills. The set up at least requires someone who can understand why the article cited is inappropriate.

To me, the whole issue as one of efficient code reuse.

On a lot of sites I am both a PHP coder and HTML/CSS coder; what attracts me to MODx is that once I have a proven set of website parts, a much less-skilled person at my company can assemble the parts together for another client and use different templates to make it look different.

Obviously there’s the reuse of layout on every page - MODx does this fine. I am also able to reuse html/MODx code across multiple templates by using chunks and snippets.

There are quite a lot of older PHP applications out there that have </head><body> in each file; I changed osCommerce to use includes and to further modularise display because I have a bunch of shops and I need to reuse the modified core on multiple sites. phpBB uses a broadly similar approach to the article, except it has a body template for each function. The MODx system is the best I’ve come across. I adore the fact that it is page-based, and snippets either have hard-coded HTML or a templating ability. There are even plugins that allow one page to have different templates as appropriate. MODx templating is highly efficient from a human-input perspective; and the caching makes up for any minor inefficiencies in the execution.

The method proposed in the article would work for a PHP site, it is just inappropriate to MODx or most CMSes. But I don’t think the author actually suggests using it for a CMS. The only person to positively connect the two was tillda - which is why I want to know what tillda sees as the benefit!

Well I for one agree with nearly everything he says in that article,.. There no reason to become defensive about MODx He’s not talking about a CMS but about templating and specifically creating another layer of "business logic" (I hate that word,.. it has nothing to do with business, why not construction logic?) MODx uses templates yes, but it at least it doesn’t have a template language, beside the occasional attempt you can find in the snippet library.

MODx is not about templating so much as about managing content (at least in my view) and about taking away peresentational complexity from content providers. In a way becasue MODx use simple tags (snippets, TVs) that can incude complex logic written in php, instead of creating another (template) ’language’ it is closer to what he is talking about in his articel then you might realize.

I think we should take what he says to heart while harnessing the power of MODx so we who extend it with our snippets and ideas don’t create our own pitfals. Modx itself isn’t doing that so far.

Quote from: PaulGregory at Aug 30, 2006, 12:42 PM

So, basically you’re suggesting we treat the template more like a snippet than a chunk, and throw out the ability to easily include snippets and chunks and document variables and other placeholders?

Maybe a little bit, but definitely not that way.

I’m afraid, that there could be quite big mess when the site gets bigger and bigger, especially the "placeholders in chunks" feature is my biggest concern. I think that this is tightening the presentation things to the system too much close. Also, we have some kind of "big snippets" (templates), middle-sized snippets (snippets, they use PHP to generate presentation HTML (not neat)) and small, HTML snippets (chunks).

I liked that article becouse it matched one idea that I had abouth month ago. This idea was about converting all HTML in templates, chunks and snippets to XML, so the output would be clear XML. By doing this, we would get rid of HTML completely, no DIVs, SPANs. To every snippet, there would be a XML-Scheme, that would grow in version number with version of that snippet (so it would be basically 100% backwards compatible). We would still construct the XML output by " easily including snippets and chunks and document variables and other placeholders". As far as I understand it, this is what the author of that article would want to say.

I 100% agree that this would need some more code, basically for rendering that XML to XHTML. But handling XML is easy in PHP5.

Doing this, templates would become Templates. We would basically be able to switch as we are able to switch CSS files.

Quote from: tillda at Aug 31, 2006, 10:26 AM

I’m afraid, that there could be quite big mess when the site gets bigger and bigger, especially the "placeholders in chunks" feature is my biggest concern. I think that this is tightening the presentation things to the system too much close. Also, we have some kind of "big snippets" (templates), middle-sized snippets (snippets, they use PHP to generate presentation HTML (not neat)) and small, HTML snippets (chunks).
...

I 100% agree that this would need some more code, basically for rendering that XML to XHTML. But handling XML is easy in PHP5.

Doing this, templates would become Templates. We would basically be able to switch as we are able to switch CSS files.

Sorry if I’m not following the point here, but I can tell you transforming XML to XHTML dynamically, during the rendering process, is not at all going to be as efficient as even the current system, nor do I understand what you mean about a big mess as the site gets bigger and bigger, or how XML-izing everything it would help address that. What would be the purpose or advantage of this, cause maybe I’m just not getting it today? And please explain more about your specific concern with "placeholders in chunks" feature; I’m not clear on what you are describing here either.