Enforcing Strict ModelView Separation in Template Engines
1–4 of 4 posts
Re: Enforcing Strict ModelView Separation in Template Engines
#2Totally enforcing separation is an almost impossible ideal. You just shifting logic from the controller to the template engine.
For example the paper describes how a designer would handle submenus as follows:
To handle submenus, have the template iterate (tail-recursively) over the list of submenu items if that menu is active.
$attr.title$ $if(attr.active)$ $attr.submenu:menuItem()$ $endif$
I prefer to send either an array to the View with the menu items and handle the logic in the template or the controller sending the list in a list with classes and id's embedded. I do not like either of them. Has anyone found a solution? I have also tried transclusion a.l.a. wikipedia to ease some of the pain of separation the designer only having to include this {{menu:top}}.
Another pet peeve of mine is that Views are more and more becoming programs (i.e ajax, Javascript?), they do not fit in neatly into a model view controller paradigm.
Whatever my comments the paper cited above by tmikew is a MUST read.
Re: Enforcing Strict ModelView Separation in Template Engines
#3Totally enforcing separation is an almost impossible ideal. You just shifting logic from the controller to the template engine. For example the paper describes how a designer would handle submenus as follows: To handle submenus, have the template iterate (tail-recursively) over the list of submenu items if that menu is active. $attr.title$ $if(attr.active)$ $attr.submenu:menuItem()$ $endif$ I prefer to send either an…
I agree it is tough. Coming from java land it always seems like one is either mixing java in the html or html in java. I have also never been totally convinced about the separate people argument. Not that it won't work, but that company's that I am familiar with don't hire both people very often the developers build both the UI and the business logic, which of course further complicates the issue, because the developers are always taking shortcuts. Everything I have ever worked on is mixed up to some extent, and it works, and we manage to maintain it. Still the arguments in the paper are compelling.
It is possible to use ajax and Javascript without getting things to mixed up, but again the discipline by the developers I am involved with is sadly lacking. There is another article I will try and find to post. Humble Dialog that fits with this paradigm.
Re: Enforcing Strict ModelView Separation in Template Engines
#4Totally enforcing separation is an almost impossible ideal. You just shifting logic from the controller to the template engine. For example the paper describes how a designer would handle submenus as follows: To handle submenus, have the template iterate (tail-recursively) over the list of submenu items if that menu is active. $attr.title$ $if(attr.active)$ $attr.submenu:menuItem()$ $endif$ I prefer to send either an…
I agree it is tough. Coming from java land it always seems like one is either mixing java in the html or html in java. I have also never been totally convinced about the separate people argument. Not that it won't work, but that company's that I am familiar with don't hire both people very often the developers build both the UI and the business logic, which of course further complicates the issue, because the develop…
With webpages becoming more and more UI's rather than documents, I was thinking one needs something like an evolved morph.
ftp://ftp.squeak.org/docs/Self-4.0-UI-Framework.pdf