cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Random thoughts on object model
Date Thu, 21 Jun 2007 16:18:37 GMT

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.

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:

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:transform src="xslt/{1}"/>

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.

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:transform src="xslt/{map:1}"/>

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:transform src="xslt/{xpath:sitemap/1}"/>

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, who is
going to maintain etc. I'm not Spring specialist, 
can custom scopes help us here? How about obtaining beans that implement certain interface?

Do you agree with what has been said above? If so, do you have ideas how this could be implemented
in modern manner? :-)

Grzegorz Kossakowski

View raw message