cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 23:18:26 GMT
Grzegorz Kossakowski skrev:
> 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
> idea:
> {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...

OK, I think I get it. Seem like a neat solution.

I'd like to know a little bit more about how you plan to manage "the one 
globally available" Object Model. Is it a component that is injected 
into the sitemap component etc? Is it part of the call stack? Or what is 
the idea?

>>> 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:
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-template-expression.xconf
> Wouldn't be needed anymore. As said earlier I want to have no
> configuration for expressions.

Make sense now.

===

I will be mainly off line until Monday.

/Daniel


Mime
View raw message