cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 22:09:57 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom napisaƂ(a):
>> Grzegorz Kossakowski skrev:
>>> or newly introduced
>>> BlockPathModule (broadly known as "servlet:" in sitemap references).
>>> This modules can be viewed as expression languages
>>> and their equivalents should be plugged into our unified expression
>>> handling mechanisms.
>> I implemented the BlockPathModule to be able to use the
>> LinkRewriterTransformer, not because it is particularly elegant to
>> implement it in this way. I would give this part lower priority.
> So how it would be done after implementing unified expressions? I
> thought that BlockPathModule would become just "servlet" expression and
> LinkRewriterTransformer would be given list of expressions instead of
> list of input modules. What's your idea?

The responsibility of the BlockPathModule is to transform one URL to 
another. The responsibility of the OM is to make a data structure of 
some kind available so that parts of it can be selected by applying an 
expression on it.

IMO the BlockPathModule stretches the concept of input modules outside 
what they are intended for. The "servlet:" object is not exactly a data 
structure and the URL is not an expression. It is also questionable what 
a JEXL expression applied on a "servlet:" object would mean.

But maybe I'm misunderstanding what you are proposing. Anyway, if you 
find a nice and neat design that includes the BlockPathModule, please 
just go ahead. If it OTH complicates your design, just skip it and focus 
on getting the design simple and easy to understand.

For link rewriting for the servlet: protocol I would prefer a special 
purpose link rewriter that takes care of the context path, servlet path 
and servlet service mount path. But that doesn't need to be part of your 


>>> Actual work will consist of:
>>> * creation of approporiate, well-thought API
>>> * implementation of various expression languages, two main
>>> implementations I want to focus on are: JXPath and Jexl/JS
>> Expression languages are implemented
>> what is lacking is using them outside the template block.
> I wasn't aware that they are already implemented and used in Cocoon.
> However, considering goals I outlined it's sure that some work with
> expression's itself is needed.
> I think that we should get rid of Avalon's dependencies and use Spring
> instead.

That would be great.

> As next step, class discovery should be implemented as we
> agreed earlier. Am I right I miss something again?

Don't know. I need a clearer idea about how you intend to use the class 
discovery mechanism to evaluate that. An example or two on what it would 
look like in e.g. the sitemap would be great.


>> I would propose that you look if the converter stuff could be within
>> your project scope, possibly by decreasing the ambition in some other
>> area. The converter idea is described here
>>, there is
>> even a partial implementation:
>> The conveter would simplify both template and cforms use considerably.
>> It would also allow us to cleanup the implementation of cforms.
> I agree that work on converters would be more valuable than artificial
> fight with IMs.
> However I fail to see the scope of converters. Your original idea was to
> create type converters that able to do bidirectional conversion between
> particular type and string and you thought that it would be reasonable
> to have only one per type.

Already that would be a great addition.

> Someone suggested that it would be great to
> have type<->XML converters too.

I'm against that. It would blur the scope and complicate the integration 
in the rest of Cocoon considerably.

> Someone else asked for being able to
> have many converters for single type and be able to have a choice which
> to choose in particular situation.

This was mainly for handling dates and numerals, like for the coverters 
in CForm. So that you could write something like share#percent or 
today#daytime, (where the first part is the object and the second the 

> I think that I could take converters into account but would like to hear
> your opinion what are the limits of flexibility they should give.

They should IMO only be String -> String. I think the selectors would be 
nice for handling L10N with a minimum of expression writing.


View raw message