Christopher Oliver wrote:<snip>
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
Yesterday, I was trying to create another view for the flow layer, similar to a subset of JSTL, using Jexl
Just one question: why transformers?
<snip>
maybe you are not aware of the fact that Cocoon is divided between two schools:
- the generator-oriented - the transformer-oriented
I didn't know that.
I think I reside on the first school since generators are much harder to *abuse* than transformers.
During my consulting, i've seen pipelines composed by something like 6 transformers and 4 actions that could have been rewritten with 10 lines of java code inside an XSP.
And, mind you, not because those people didn't know how to write java, but simply because they didn't *KNOW* it was so easy with XSP.
Admittedly, XSP has the *huge* drawback of the steep-as-hell learning curve of XSLT-based logicsheets, expecially nested ones.
Anyway, have you ever seen X:Forge? (http://xforge.sourceforge.net/)
No, I'll take a look.
As for me I was more interested in getting the user friendly behavior of the embedded expression language of Velocity and JSTL provides compared to the JPath Xsp logic sheet. Although it is an interpreted solution, implementing this behavior as a transformer seemed like the easiest way.
<snip profiling and conditional tags>
you have velocity and xsp that provide that functionality, why do you want another one in the transformation side? I don't understand.
You have a point. Maybe having too many template languages is a bad thing.
That's for sure.
But I was thinking that the JSTL expression language may become more well known than Velocity and unlike Velocity the Jexl template is XML.
You have a point about JSTL becoming more popular than Velocity.
As for the Jpath logic sheet, as I mentioned above, it doesn't have an embedded expression language, so you have to use <xsp:attribute> which seems very unfriendly.
Agreed.
<snip performance concerns>
Please, provide a wider context as for what you are trying to achieve and what problems you are trying to solve because it's not clear at all.
I'm not being critic, just want to know the full context because I'm not able to do any costructive criticism without one.
I think what I'm trying to achieve is to flush out what the "view" layer API(s) to communicate with the flow layer should be.
Ok, I see. Keep up the good job.
There appear to be three available expression languages for use in page templates:
- XPath - JSTL - Velocity
I think it makes sense to support each of these. My current implementations (JXPathTransformer, JexlTransformer, and FlowVelocityGenerator) leave something to be desired, but I would like to agree on the interfaces exposed in the template language(s) before worrying too much about the implementation (generator vs transformer, should we use objectModel or other approach to pass flow bean and continuation, etc).
So, I'll put these in the scratchpad for people to experiment with while we talk about design.
My main concern here is: what objects do we want to expose to the page template and how do we want to handle variable "scoping"?
Here are some of the objects you may or may not want to expose:
* flowscript bean object * flowscript web continuation * request * response * session * context * parameters passed from the sitemap * global sitemap variables * various stuff stashed in the object model by other sitemap components * various objects made accessible throught input modules
And how should these objects be exposed in each of the expression languages? And should they share the same "scope"? Or should there be some kind of "import" feature, where you could pick which objects you want to expose?
Regards,
Chris
