5) control should be inverted: the template must be a view, it should be 'pushed' the data in, it should not contain any data-pulling logic other than the one used to pull data from the dataset passed on by the underlying controlling stage.
Some restrictions on the push model : it requires the pushed data to be fetched by the flow before being processed by the view. Although this is fine in most simple cases, there are some applications where large datasets are used to build the view, and SAX-based streaming really is necessary (e.g. database extraction).
yes. this is why the template system behaving as a transformer should be declarative on the input stream (push) and procedural on the corollary objects (pull) such as request,session,context,flow,deli,sitemap-parameters and what not.
if behaving as a generator, it should be declerative only on the root template and then act completely procedural.
In that case, we must have an hybrid model where the flow pushed information that allows the view to pull its content. E.g. the flow will push the parameters of a SQL query which is executed by the view and has its result streamed.
*NO*!
the view shouldn't execute anything! it's up to the controller to do stuff, either by connecting to objects directly or by invoquing a generator before the template system acting as a transformer.
you are mixing concerns!
- o -
IMHO, the template language which is closer to the optimum is XSLT but only with one change:
FORGET THE XML SYNTAX!
I'm entering wild mode now, so bear with me. Suppose you had:
1) a syntax that is simple and efficient to describe a stylesheet
2) a defined object model accessible thru regular xpath queries
I guess you mean that flow context is made available to the stylesheet through XPath-enabled variables, right ?
yes. but not only that. the request, session, context and sitemap parameters should be as well. also blocks should have the ability to plug in their own objects into this, such as deli, for example.
3) no ability to call extensions
It's soooo useful to call some helper Java classes in XSLT to overcome the limitations of XPath...
Again, you are thinking about active views. But the view shouldn't need to use any logic whatsoever to act *on* the data, but only to display it. It's somebody else's concern to provide the 'proper' data to the view.
You reinvented XSLScript ! It's at http://www.pault.com/pault/prod/XSLScript
Ah, didn't know this, but gee, the syntax is horrible, can be much easier than that.
Ah, and how does this fit with caching ?
good question.
since the output is dependent on:
- the input stream - the values of all the parameters involved
but the transformer knows about all the parameters involved since the template doesn't have build-in logic that can use to produce content which not dependent on the parameters, the template system can implement cachable if it keeps track of the parameters asked by the template and if they remained the same.
i'm not sure if this is worth the task, but it's doable.
Stefano.
