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/
