cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Random thoughts on object model
Date Tue, 26 Jun 2007 22:30:21 GMT
Daniel Fagerstrom pisze:
> 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.

Agreed.

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

I think that all objects from all frames should be visible. Details are put below.

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

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

As I said, in general it will be visible. However, if "map:" language decides that only last
"/sitemap" collection is available by default 
and "/sitemap" from the frame below is available at "../" it's fine. Map language can introduce
such behaviour but it's really a fa├žade for 
a linear list (stack).

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

After thinking a while I'm not sure if analogy is exactly accurate but I had something like
this in mind:
Tag's supporters says that one should give up trying to create awfully complicated hierarchies
that will never be perfect enough and just 
leave everything messed up but with labels attached. Same here, I want to say that we should
not try to invent clever mechanisms because 
hierarchy can make sense in one context (sitemaps) and in other it's worthless. Introducing
too much clever mechanisms will pollute APIs and 
will not bring anything really useful.

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

Is it that simple to just ask ServiceManager for Spring component by using bean id and all
functionality (like scopes) will just normally work?

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

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

Ok.

> 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 ;)

;)
I hope my explanation put above explain what I mean.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message