cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Flow views, scratchpad taglib, and writing transformers
Date Wed, 26 Mar 2003 16:48:48 GMT
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



Mime
View raw message