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.
OK.
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.
Agree.
Other way is introducing some kind of guard (concept from
double-linked-list implementations) that would mark where "new" local
stack begins.
Yes.
...
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.
OK.
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.
/Daniel
