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 Wed, 27 Jun 2007 21:56:27 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>>> What's really important it _is_ allowed to have several context with 
>>> the same name in the stack. See my answer few lines below :)
>>> 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?
> In general, yes. I think that in most cases rule "first match wins" 
> should be sufficient. This way if there are two /request-param maps and 
> both contain "foo" key only value of the map pushed on a stack last will 
> be returned. Of course, nothing stops you from collecting all "foo" 
> values from all levels if it's really needed for some reason.
> My idea is to not try to invent some general visibility-mechanism that 
> would turn out to be not general enough and make EL responsible for 
> visibility because only EL implementation knows what should be really 
> visible and what not when the expression is evaluated.


>>> 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? 
> Yes, and that's why I would like to see stacks more local so OM sharing 
> between servlets is avoided.


> Other way is introducing some kind of guard (concept from 
> double-linked-list implementations) that would mark where "new" local 
> stack begins.


>>> 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?
> Yes, you are right. "sitemap" is collection because there is more than 
> one "sitemap" frame in the stack it it's *only JXPath* behaviour to 
> collect all "sitemap" frames and treat them as one big collection. It's 
> exactly the same if you have following XML:
> <foo>
>   <bar id="1"/>
>   <bar id="2"/>
> </foo>
> And XPath like this: "/foo/bar/@id".
> Such a behaviour justifies introduction of map: EL that gives you other 
> interpretation of data in OM that is more natural in sitemap's context.


> Thinking about "sitemap[position()=last()]" syntax I'm starting to 
> realize that stack should allow to iterate it's elements in reversed 
> order so stack semantics are retained.
>> What do you mean with "'manually inject' something in Avalon component"?
> Current implementation of treeprocessor creates PreparedVariableResolver 
> class and passes it a ServiceManager. By "manual injection" I meant 
> obtaining a Spring-managed component in Avalon-managed component by 
> using explicit call to some kind of bridge. I don't really know details 
> of Spring-Avalon bridges we have in Cocoon.

Don't remember the details. But the main steps are: The Avalon 
configuration is translated to a Spring bean configuration, the bean 
configuration is used for creating the (Avalon) bean, and the 
o.a.c.core.container.spring.avalon.AvalonBeanPostProcessor is used for 
handling the Avalon life cycle steps that not has a direct Spring 
counter part.

> Is it that simple to just ask ServiceManager for Spring component by 
> using bean id

In general, yes.

> and all functionality (like scopes) will just normally work?

Maybe ;)

>> 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 just want to get an instance of EL resolver from treprocessor (that 
> will be Spring bean) and be sure that its dependency (on Object Model 
> that is scoped) is properly initialized.

The current life cycle of resolvers, service managers and object models 
and their relations to sub sitemap calls, is really hard to follow. I 
think it would be better to try to put all such information in one or 
serveral call stacks, and use something like call scope for accessing 
the info.

Then the object model could be a facade against the call stack. I doubt 
that it is worth the effort to try to extend the current model.


View raw message