cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 22:44:20 GMT
Daniel Fagerstrom napisaƂ(a):
> 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.

I wasn't clear enough, I do not propose to "servlet:" become an object
that will be included in OM. I will give you an examples explaining the
{xpath:/cocoon/request/parameters/someParameter} means that we apply
expression "/cocoon/request/parameters/someParameter" in "xpath"
language on default (the one globally available) Object Model, now:
{servlet:forms:/some/path} means that we apply expression
"forms:/some/path" in "servlet" language. The difference is that this
expression is not applied on default Object Model. Servlet language
would just ignore OM and process this expression the same way the
BlockModulePath does now.
That means we allow expression languages to ignore OM and do on their
responsibility possible other way of applying expression. This leads to
a little bit more general understanding of Expression (intentionally
written with capital letter) that just returns value of passed
expression no matter how data needed to calculate it is being obtained.
Of course for most cases expression calculate their values while
operating on OM so that's why we provide it. To avoid every expression
language reinvent the wheel and keep everything coherent. However, we
allow exceptions...

>> 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 think it's has nothing to do with sitemap. By class dicovery I mean
that expression would be discovered and registered in expression
compiler registry automatically so this file:
Wouldn't be needed anymore. As said earlier I want to have no
configuration for expressions.

>> 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.

I agree that at this stage we should not bother ourselves with this idea.

>> 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 selector).
>> 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.


Grzegorz Kossakowski

View raw message