You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2003/03/24 18:55:08 UTC
Flow views, scratchpad taglib, and writing transformers
Yesterday, I was trying to create another view for the flow layer,
similar to a subset of JSTL, using Jexl
http://jakarta.apache.org/commons/jexl
I started with Marcus Crafter's JPathTransformer, and in the process of
writing JexlTransformer, I also attempted to add support for for-each
and choose/when/otherwise to JPathTransformer (both extend
AbstractSAXTransformer). I also added support for expanding xpath
expressions inside attribute values (similar to the way JSTL's
expression language works). Oh yeah, another thing I changed is to make
the continuation available as an XPath variable so you don't need
jpath:continuation anymore.
Anyway, I was trying to get both of these to be equal in functionality
with Velocity and the JPath Xsp logic sheet.
I've placed a copy of the source code and samples of the same template
using jexl, jxpath, and velocity here:
http://www.primaryinterface.com/cocoon/transformation/
As I was doing this, I kept thinking what a poor framework
AbstractSAXTransformer seemed to be (uses implementation inheritance,
has protected variables with side-effects, e.g. ignoreEventsCount and
ignoreHooksCount, no real API), and that a much better API for writing
transformers was needed.
Then I came across Volker Schmitt's taglib in the scratchpad which looks
like exactly what I wanted:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102227009022017&w=2
In my opinion, given the Cocoon flow layer and Cocoon's support for XSL,
we don't don't need extensive tag libraries, but instead just the
equivalent of a subset of JSTL core flow tags, and its expression language:
<if/>
<forEach/>
<choose/>
<out/>
In other words, just enough to navigate through the contents of the
"bean" object passed from the flow layer, in order to render output.
This is equivalent to the functionality Ovidiu included in the jpath Xsp
logic sheet.
And this is the functionality that JexlTransformer and JXPathTransformer
provide, with Jexl and JXPath as the expression languages, respectively.
I would like to reimplement JexlTransformer and JXPathTransformer using
taglib (if anyone want's to help, let me know).
Assuming this works, I'd also like to reimplement XMLFormTransformer
using taglib and move taglib to the core as a proper API for writing
transformers in the future.
Thoughts?
Regards,
Chris
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Christopher Oliver <re...@verizon.net>.
I just noticed "taglib" had already been moved to a block a while ago.
Christopher Oliver wrote:
>
> Then I came across Volker Schmitt's taglib in the scratchpad which looks
> like exactly what I wanted:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102227009022017&w=2
>
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Christopher Oliver <re...@verizon.net>.
Stefano Mazzocchi wrote:
> Christopher Oliver wrote:
>
>> 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
<snip>
>>>
>>>
>>> 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
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Christopher Oliver <re...@verizon.net>.
Stefano Mazzocchi wrote:
>
> maybe you are not aware of the fact that Cocoon is divided between two
> schools:
>
> - the generator-oriented
> - the transformer-oriented
>
> I think I reside on the first school since generators are much harder to
> *abuse* than transformers.
>
I can think of at least one other reason for preferring generators: you
get a file name and line number in your error messages.
Chris
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Stefano Mazzocchi <st...@apache.org>.
Christopher Oliver wrote:
> 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
>>>
>>> http://jakarta.apache.org/commons/jexl
>>>
>>> I started with Marcus Crafter's JPathTransformer, and in the process
>>> of writing JexlTransformer, I also attempted to add support for
>>> for-each and choose/when/otherwise to JPathTransformer (both extend
>>> AbstractSAXTransformer).
>>
>>
>> Just one question: why transformers?
>
>
> Good question. Ovidiu basically said the same thing. He pointed out that
> ideally XML processing of a Jexl/JXPath template should happen only
> once, to convert the page template to the final XML and later generate a
> Java class, similar to what JSP does. This should be much faster than
> the usage pattern of starting with a page template containing
> JXPath/Jexl instructions that will be evaluated at runtime to generate
> an XML document - which implementing the JXPath/Jexl template processor
> as a tranformer leads to.
>
> I think Marcus starting implementing JPathTranformer because he didn't
> want to use Xsp: he was on MacOS and didn't want to depend on Javac.
> This shouldn't matter anymore now that the eclipse Java compiler is
> built into Cocoon.
maybe you are not aware of the fact that Cocoon is divided between two
schools:
- the generator-oriented
- the transformer-oriented
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/)
> 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.
>
> How is your profiling of Cocoon coming?
Oh, it's more or less finished. I think that we are generating too many
strings, but couldn't really find out a single point that was generating
too many of them.
overall, Cocoon seems pretty decently optimized for memory consumption.
> It would be interesting to find
> out if a compiled versus interpreted template has a measurable
> difference in the overall performance of Cocoon.
I did memory profiling, not speed profiling.
>>> Then I came across Volker Schmitt's taglib in the scratchpad which
>>> looks like exactly what I wanted:
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102227009022017&w=2
>>>
>>> In my opinion, given the Cocoon flow layer and Cocoon's support for
>>> XSL, we don't don't need extensive tag libraries, but instead just
>>> the equivalent of a subset of JSTL core flow tags, and its expression
>>> language:
>>>
>>> <if/>
>>> <forEach/>
>>> <choose/>
>>> <out/>
>>
>>
>>
>> aahhhhhhhhhhhhhhhhhhhhhhhhhhh!
>>
>> the infamous <if/> anti-pattern: every markup language grows to
>> include the <if/> element!
>>
>> beware!
>>
>
> <if> and <choose> are needed to test for the presence of optional and/or
> alternative values in the bean object.
I know you need conditionals and everytime I see something like <if> I
really have a bad feeling. XSLT included.
>>> In other words, just enough to navigate through the contents of the
>>> "bean" object passed from the flow layer, in order to render output.
>>
>>
>>
>> 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.
The only thing that worries me is performance. If somebody can prove
that interpreted templates are comparatively efficient to compiled ones,
I'll be happy to consider XSP deprecated in favor of a more
taglib-oriented solution.
But, I never had time to do such extensive profiling.
>>> This is equivalent to the functionality Ovidiu included in the jpath
>>> Xsp logic sheet.
>>>
>>> And this is the functionality that JexlTransformer and
>>> JXPathTransformer provide, with Jexl and JXPath as the expression
>>> languages, respectively.
>>>
>>> I would like to reimplement JexlTransformer and JXPathTransformer
>>> using taglib (if anyone want's to help, let me know).
>>>
>>> Assuming this works, I'd also like to reimplement XMLFormTransformer
>>> using taglib and move taglib to the core as a proper API for writing
>>> transformers in the future.
>>
>>
>>
>> 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.
Stefano.
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Christopher Oliver <re...@verizon.net>.
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
>>
>> http://jakarta.apache.org/commons/jexl
>>
>> I started with Marcus Crafter's JPathTransformer, and in the process
>> of writing JexlTransformer, I also attempted to add support for
>> for-each and choose/when/otherwise to JPathTransformer (both extend
>> AbstractSAXTransformer).
>
> Just one question: why transformers?
Good question. Ovidiu basically said the same thing. He pointed out that
ideally XML processing of a Jexl/JXPath template should happen only
once, to convert the page template to the final XML and later generate a
Java class, similar to what JSP does. This should be much faster than
the usage pattern of starting with a page template containing
JXPath/Jexl instructions that will be evaluated at runtime to generate
an XML document - which implementing the JXPath/Jexl template processor
as a tranformer leads to.
I think Marcus starting implementing JPathTranformer because he didn't
want to use Xsp: he was on MacOS and didn't want to depend on Javac.
This shouldn't matter anymore now that the eclipse Java compiler is
built into Cocoon.
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.
How is your profiling of Cocoon coming? It would be interesting to find
out if a compiled versus interpreted template has a measurable
difference in the overall performance of Cocoon.
>
>> Then I came across Volker Schmitt's taglib in the scratchpad which
>> looks like exactly what I wanted:
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102227009022017&w=2
>>
>> In my opinion, given the Cocoon flow layer and Cocoon's support for
>> XSL, we don't don't need extensive tag libraries, but instead just the
>> equivalent of a subset of JSTL core flow tags, and its expression
>> language:
>>
>> <if/>
>> <forEach/>
>> <choose/>
>> <out/>
>
>
> aahhhhhhhhhhhhhhhhhhhhhhhhhhh!
>
> the infamous <if/> anti-pattern: every markup language grows to include
> the <if/> element!
>
> beware!
>
<if> and <choose> are needed to test for the presence of optional and/or
alternative values in the bean object.
>> In other words, just enough to navigate through the contents of the
>> "bean" object passed from the flow layer, in order to render output.
>
>
> 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. But I was thinking that the JSTL expression language may become
more well known than Velocity and unlike Velocity the Jexl template is
XML. 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.
>
>> This is equivalent to the functionality Ovidiu included in the jpath
>> Xsp logic sheet.
>>
>> And this is the functionality that JexlTransformer and
>> JXPathTransformer provide, with Jexl and JXPath as the expression
>> languages, respectively.
>>
>> I would like to reimplement JexlTransformer and JXPathTransformer
>> using taglib (if anyone want's to help, let me know).
>>
>> Assuming this works, I'd also like to reimplement XMLFormTransformer
>> using taglib and move taglib to the core as a proper API for writing
>> transformers in the future.
>
>
> 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.
Regards,
Chris
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, March 25, 2003, at 09:32 AM, Stefano Mazzocchi wrote:
>
>> In other words, just enough to navigate through the contents of the
>> "bean" object passed from the flow layer, in order to render output.
>
> you have velocity and xsp that provide that functionality, why do you
> want another one in the transformation side? I don't understand.
Some prefer the transformer 'paradigm' to the xsp one?
Velocity language looks 'ugly'? (IMHO)
I agree what you say about <if/> though .... we had this discussion
before :)
regards Jeremy
PS. Sorry, I am a bit behind .....
"You know the world is going crazy when
the best rapper is a white guy,
the best golfer is a black guy,
France is accusing the US of arrogance and
Germany doesn't want to go to war."
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Stefano Mazzocchi <st...@apache.org>.
Christopher Oliver wrote:
> Yesterday, I was trying to create another view for the flow layer,
> similar to a subset of JSTL, using Jexl
>
> http://jakarta.apache.org/commons/jexl
>
> I started with Marcus Crafter's JPathTransformer, and in the process of
> writing JexlTransformer, I also attempted to add support for for-each
> and choose/when/otherwise to JPathTransformer (both extend
> AbstractSAXTransformer). I also added support for expanding xpath
> expressions inside attribute values (similar to the way JSTL's
> expression language works). Oh yeah, another thing I changed is to make
> the continuation available as an XPath variable so you don't need
> jpath:continuation anymore.
>
> Anyway, I was trying to get both of these to be equal in functionality
> with Velocity and the JPath Xsp logic sheet.
>
> I've placed a copy of the source code and samples of the same template
> using jexl, jxpath, and velocity here:
>
> http://www.primaryinterface.com/cocoon/transformation/
>
> As I was doing this, I kept thinking what a poor framework
> AbstractSAXTransformer seemed to be (uses implementation inheritance,
> has protected variables with side-effects, e.g. ignoreEventsCount and
> ignoreHooksCount, no real API), and that a much better API for writing
> transformers was needed.
Just one question: why transformers?
> Then I came across Volker Schmitt's taglib in the scratchpad which looks
> like exactly what I wanted:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102227009022017&w=2
>
> In my opinion, given the Cocoon flow layer and Cocoon's support for XSL,
> we don't don't need extensive tag libraries, but instead just the
> equivalent of a subset of JSTL core flow tags, and its expression language:
>
> <if/>
> <forEach/>
> <choose/>
> <out/>
aahhhhhhhhhhhhhhhhhhhhhhhhhhh!
the infamous <if/> anti-pattern: every markup language grows to include
the <if/> element!
beware!
> In other words, just enough to navigate through the contents of the
> "bean" object passed from the flow layer, in order to render output.
you have velocity and xsp that provide that functionality, why do you
want another one in the transformation side? I don't understand.
> This is equivalent to the functionality Ovidiu included in the jpath Xsp
> logic sheet.
>
> And this is the functionality that JexlTransformer and JXPathTransformer
> provide, with Jexl and JXPath as the expression languages, respectively.
>
> I would like to reimplement JexlTransformer and JXPathTransformer using
> taglib (if anyone want's to help, let me know).
>
> Assuming this works, I'd also like to reimplement XMLFormTransformer
> using taglib and move taglib to the core as a proper API for writing
> transformers in the future.
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.
TIA
Stefano.
Re: Flow views, scratchpad taglib, and writing transformers
Posted by Vadim Gritsenko <va...@verizon.net>.
Christopher Oliver wrote:
<snip/>
> Anyway, I was trying to get both of these to be equal in functionality
> with Velocity and the JPath Xsp logic sheet.
<snip/>
> This is equivalent to the functionality Ovidiu included in the jpath
> Xsp logic sheet.
>
> And this is the functionality that JexlTransformer and
> JXPathTransformer provide, with Jexl and JXPath as the expression
> languages, respectively.
>
> I would like to reimplement JexlTransformer and JXPathTransformer
> using taglib (if anyone want's to help, let me know).
>
> Assuming this works, I'd also like to reimplement XMLFormTransformer
> using taglib and move taglib to the core as a proper API for writing
> transformers in the future.
>
> Thoughts?
+1 for integration/unification effort.
Vadim
> Regards,
>
> Chris