cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Random thoughts on object model
Date Mon, 25 Jun 2007 23:41:47 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
> Yes, I started to wonder ;) I'll have vacation 7 July to 5 August and 
> will be sailing most of the time, so I will not answer email that often 
> during that period. Hopefully other people at the list will be present 
> and able to discuss with you.

We have 11 days left for discussion, not that bad I think. Assuming, of course, that you are
able to participate in the 
discussion during this eleven days, are you?

Speaking for myself, it's about 12 hours left to my last exam, after writing it I can devote
my time fully to Cocoon.

>> Let's think now about accessing such values hold in context. In a 
>> sitemap we have constructs like {1}, or {../barValue}. It's our own, 
>> simple expression language. Given we have generic EL API we should 
>> treat sitemap's language the same way xpath or jexl is treated. The 
>> only difference should be that sitemap language operates on subset of 
>> whole OM consisting of contexts registered by sitemap componenets. So 
>> we would introduce "map" language and above snippet would like this one:
>> <map:match pattern="foo/**">
>>   <map:act type="barAction">
>>     <map:generate src="{map:barValue}"/>
>>   </map:act>
>>   <map:transform src="xslt/{map:1}"/>
>>   <map:serialize/>
>> </map:match>
> I assume that one can configure the map: language to be the default EL, 
> and that the default EL can be used without a prefix, so that we keep 
> back compatibility?

Yes, default EL could be configured but I'm not sure if I'll be able to ensure a back-compatiblity
everywhere. What 
about pushing sitemap language version to 1.1 and having a really clean contracts and implementation?
Don't be alarmed, 
I don't want to revolutionize things too much. Nevertheless, I think it's better to clearly
state that something has 
changed by increasing version number and providing good migration guides than pretending that
nothing has changed and 
make users frustrated because something does not work (and we promised it will).

Of course, someone sticking to 1.0 version will be able to use old syntax. What about such
a back-compatiblity?

>> I want to emphasize that I would like to see sitemap's contexts 
>> maintained and accessed the same way e.g. flow attributes are 
>> accessed. Let's assume that that sitemap contexts are put under 
>> "/sitemap/" in OM so such constructs are valid:
>> <map:match pattern="foo/**">
>>   <map:act type="barAction">
>>     <map:generate src="{xpath:/sitemap/barValue}"/>
>>   </map:act>
>>   <map:transform src="xslt/{xpath:sitemap/1}"/>
>>   <map:serialize/>
>> </map:match>
> That kind of hierarchy seem like overkill to me, why not just 
> {xpath:/barValue} and {xpath:/1}?

In original proposal I was talking about _named_ collections of objects. This way sitemap
engine contributes to 
"/sitemap" collection, some preprocessing intizialtion that exposes Request object puts it
as "/request" etc.

What's really important it _is_ allowed to have several context with the same name in the
stack. See my answer few lines 
below :)

> For a stack of hierarchical contexts, you need to think a little bit 
> more about how to the overriding between stack levels is supposed to work.

I think you are refering to the situation like this:
<map:match pattern="foo/**">
   <map:act type="barAction">
     <map:generate src="{map:barValue}/{map:../1}"/>
   <map:transform src="xslt/{map:1}"/>


I think that we should not invent any mechanism of overriding between stack levels. I would
prefer to have not introduce 
any hierarchy in OM and allow to push more than one collection with given name. The kind of
hierarchy would be preserved 
by order on the stack. "Map" language that introduces hierarchy would just search the OM for
all "/sitemap" occurances 
and interpret "../" symbol as "go one step back in the list". I'll illustrate it using example
put above:
1. matcher pushes "/sitemap" = {"1": "sth"} on the stack
2. action pushes "/sitemap" = {"barValue": "value"}
3. expression {map:barValue} is solved:
    a) the stack is searched for all "/sitemap" collections and the EL has a list with *preserved*
    b) the last collection ("/sitemap" = {"barValue": "value"}) is used to obtain "barValue"
4. expression {map:../1} is solved:
    a) the stack is searched for all "/sitemap" collections and the EL has a list with *preserved*
    b) last but one collection ("/sitemap" = {"1": "sth"}) is used to obtain "1" value
5. the collection pushed by action is popped

I think that this solution is cleaner and more scalable. It's like tagging vs categories,
I think that everone prefers 
tags more these days ;-)

What's more, one could use following sytnax:
for obtaining that value inside <map:act>. This way the map: EL is really syntatic sugar
that makes someone a feeling 
that there is a hierarchy.


> Absolutely, with custom scopes we can use ordinary dependency injection 
> for getting beans from the "current context".

Will that work for components that are not initialized by Spring? Do we have a functionality
to "manually inject" 
something in Avalon component and taking advantage of Spring goodies at the same time?

> I implemented a call scope that is intended for such use, see 

> and 

> for the implementation and 

> and 

> for configurations.
> I wrote a little bit about the idea in 

Haven't read it yet, I'll do it after exam.

> Back then I 
> had the idea of having a special sitemap scope. Now I'm more leaning 
> towards have a generic call scope that is used both for the servlet 
> service stack, the stack used for sub sitemap calls in the sitemap 
> implementation and for the more fine grained context that are needed for 
> the expression handling.

I'm not really sure if it's a good idea. I think that OM should not be shared between servlets.
What is advantage of 
having one, big stack where everything is pushed?

> This would require some generalization of the current call scope, that 
> only takes care about request, response and context objects.
> We can get into more details if you agree about the main direction.

I agree with most of what you said. I fear it will be much more difficult to convince you
(and others) to the idea of 
flat OM. Yet, it's my only gut feeling...

Thanks for comments.

Grzegorz Kossakowski

View raw message