Grzegorz Kossakowski skrev:
Hi,
Some of you may wonder if I still remember that I participate in GSoC
this summer. The answer is positive, I remember but I'm in mid of
exams session at university and it's really exhausting experience.
Preparations soak almost all of my energy and take nearly one hundred
per cent of my free time. I explained my excuse very well, let's move to
main topic, now.
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.
I thought a little about Object Model for Cocoon on which expressions
are going to be evaluated. I already set the main goals for Object Model
here: http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
NOTE: Everything discussed below is about situation when we consider
only one servlet (so there is no inter-block communication, environment
sharing etc.). Multi-block considerations are left for next discussions.
I would like to talk about contexts for Object Model's parts. Let's
evaluate this simple example:
<map:match pattern="foo/**">
<map:act type="barAction">
<map:generate src="{barValue}"/>
</map:act>
<map:transform src="xslt/{1}"/>
<map:serialize/>
</map:match>
In the above snippet we can see several contexts introduced by sitemap's
constructs where values collections are meaningful and valid:
1. Matcher exposes its wildcard's matches for use inside <map:match>
element. Values are named by numbering.
2. Inside matcher's context new one is introduce by action. Inside this
context values returned as a HashMap by action's act() are meaningful
and accessible.
It's obvious that values from outer context (matcher's one) are
available even if inner context is introduced by action. Conclusion that
contexts are extended and not obstructed leads is us to think about
contexts' stack or list. Let's assume from now that context is just a
named collection of objects.
Each time new context is introduced by sitemap element (or flowscript,
or something else) it is included to the list of available contexts and
of course removed when it is not valid any more.
A stack of collections seem like the right way to go.
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?
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}?
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.
Here we used xpath to access the same values the map language gives us.
The conclusion is that we introduce map langauge for our convenience but
sitemap just uses standard OM and IM APIs, concepts and techniques.
I wonder how this could be implemented, where the list of contexts
should be held,
In a thread local stack, IMO.
who is going to maintain etc.
The caller of a sub context: push the new context, call the subcontext,
return from the subcontext, pop the context stack.
I'm not Spring specialist,
can custom scopes help us here?
Absolutely, with custom scopes we can use ordinary dependency injection
for getting beans from the "current context".
I implemented a call scope that is intended for such use, see
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/callstack/
and
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/
for the implementation and
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/resources/META-INF/cocoon/spring/cocoon-callstack-environment.xml
and
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-block-path-module.xml
for configurations.
I wrote a little bit about the idea in
http://marc.info/?l=xml-cocoon-dev&m=116593632301167&w=2. 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.
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.
How about obtaining beans that implement
certain interface?
That can be done with the bean map of the cocoon-spring-configurator.
Do you agree with what has been said above?
Yes.
If so, do you have ideas how
this could be implemented in modern manner? :-)
See above.
/Daniel
