cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Random thoughts on object model
Date Tue, 26 Jun 2007 18:34:05 GMT
Grzegorz Kossakowski skrev:
> 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?
Such a back compatibility seem reasonable, but I think we can wait with 
that discussion until you suggest specific changes. Before that the 
subject is a little bit too abstract.

>>> 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.
I see, but that still is a 2 level hierarchy, so rules for what objects 
that are visible from earlier frames in the stack is still needed.

> 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:act>
>   <map:transform src="xslt/{map:1}"/>
>   <map:serialize/>
> </map:match>
> Right?
No ;) I was rather considering the case when you have something like 
/request-param/foo="bar" at the level n-1 and a /request-param map at 
level n (the current level). Should "foo" be visible in such a case?

> 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* order
>    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* order
>    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 I agree ;) But need some more details about item 3. If 
there is no "/sitemap" collection, e.g., in the top frame of the stack, 
will the stack be searched downwards until a "/sitemap" collection is 
found? Also (as allready asked above) if the topmost frame contains 
"/sitemap"={"barValue":"1"} and the stack frame below contains 
"/sitemap"={"fooValue":"2"}, will the "fooValue" be visible?

> 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 ;-)
I don't follow the analogy, could you expand on it?

> What's more, one could use following sytnax:
> "sitemap[position()=last()-1]/barValue"
> 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.
Seem neat at first sight, but it would mean that "sitemap" should be a 
list of collections rather than a collection and that you would need to 
use "sitemap[position()=last()]/barValue" to get the current value 
rather than "sitemap/barValue", wouldn't it?

>> 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?
What do you mean with "'manually inject' something in Avalon component"?

In general you will need a factory bean for each bean you want to get 
from a custom scope. But the beans could be collections, so I don't know 
if it is a limitation. Furthermore it might be possible to inject the 
needed factory beans dynamically if more flexibility is needed. But I 
need to understand the use case to be able to formulate any more 
specific ideas.

>> 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.
I'm not sure either.

> What is advantage of having one, big stack where everything is pushed?
My main reason is from how the API for custom scopes is defined. AFAICS 
we would need one scope implementation for respectively servlet service, 
sitemap and "OM" scope if we don't use a common stack. But let us defer 
the implementation problems until later. First we should get the 
concepts right.

>> 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...
I don't see why that should be so hard. But as you suggest a 
collection-of-collections OM, I'm not sure that you even are trying ;)


View raw message