cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: environment abstraction in Cocoon 2.2
Date Tue, 10 Oct 2006 13:45:27 GMT
On 10/9/06, Carsten Ziegeler <cziegeler@apache.org> wrote:

<snip/>

> > I think we have to change this as well and add all request relevant
> > information as attributes of the request object. This would then allow
> > to easily use other techniques/frameworks - like you could then just
> > forward your request from Cocoon flow to a JSP doing the rendering.
> > But just adding all this stuff to request attributes is not that easy as
> > unfortunately sub request are sharing the attributes with the main
> > request. So whenever you use the cocoon protocol the main request and
> > the sub request use the same set of attributes.
> >
> > I hoped to solve these problems for 2.2 but I never had a good idea -
> > but it's something we should definitly work on for the next releases.

No real solutions, just some ideas to get discussion going. I can see
two possible approaches, both of which have problems (and you've
probably already considered and discarded):

First, what about just some attribute container class that tracks the
attribute and parent/child attribute if present?  Something like:

class HierarchicalAttribute {
   Attribute attr;
   HierarchicalAttribute parentl;
}

Or swap parent with child depending on what semantics work best, but
the basic idea remains the same:  you've got a linked list of
attributes, as you work up or down the request and subrequests.
Alternately, just use a List that you can walk in whatever order you
want, maybe extended to have push/pop stack semantics.

The problem here is that this breaks the regular attribute access
semantics. You can't just get the attribute but rather you have to get
the attribute container and then get the real attribute from the
Hierarchy (or List, or whatever).  That means you've got to use some
Cocoon specific wrapper to access the real attribute if you want to
hide the implementation, but since access to the actual attribute is
Cocoon specific is that really a problem? I think yes...

The second approach seems even more of a hack, but removes the problem
for direct access.  Again you need a Cocoon specific wrapper, but this
time for adding the attributes instead of accessing them. In this
case, you first determine if the attribute is already present and if
so then you store it again with some new name and then store the
subrequest attributes as normal.  So, in this case if  you've got
something like "CocconAttr" it becomes "CocoonAttr-1"  when the second
instance is stored and if another subrequest comes along you get
"CocoonAttr-2", etc. The big problem with this approach is that you
need some way to automatically rename the attributes back to normal
when the subrequest ends and this seems problematic.

I'll go finish up my coffee now...

-- 
Peter Hunsberger

Mime
View raw message