cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeroen Reijn <>
Subject Re: set a session attribute in the sitemap
Date Tue, 19 Dec 2006 22:03:03 GMT

Mark Lundquist wrote:
> On Dec 19, 2006, at 11:04 AM, Jeroen Reijn wrote:
>> Hmm I was a little bit to fast with the trigger :-)
>> I mean that it should become
>> <map:act type="session-propagator">
>>  <map:parameter name="example1" value="xxx"/>
>> </map:act>
> Hmmm, I don't think so...  In your example, the action is configured 
> with the name "setteraction".  Maybe you got mixed up because in your 
> reply to Kai Munz' original question, you gave an example using the 
> SessionPropagatorAction, and in that example the component was 
> configured with the name "session-propagator"?

Well if I look back at my emails, I'm afraid that the emails are meant 
the way I wanted them. Both session-propagator emails were a reply to 
the part where Roel had problems with a 'namespace not defined' error in 
his sitemap after trying the SessionPropagatorAction with a parameter.

The one about the SetterAction was meant for you in reply about the 
sitemap usage model of the SetterAction.

> Anyway, it looks to me like there are 3 ways to do this now:
> 1) A specialized SessionPropagatorAction;
> 2) A more general SetterAction which can can be configured from a 
> hard-coded set of "modes" (session, request, object model);
> 3) A very general PropagatorAction that is configured with an OutputModule.
> #3 is the way that I have always used.
> It also looks like none of these ways conveys any advantage over the 
> others at the point of use (in the pipeline).  Do you agree?  IMHO #1 
> and #2 should be deprecated!

Well I agree that having three different ways of accomplishing things is 
a bit too much. But looking at the components I think that we could 
suggest option #1 to be deprecated, since #1 and #3 are allmost the 
same. #2 has one advantage over the other 2 IMO which is that it allows 
you to put parameters into the object model.

So if one of these three should be deprecated I would go for #1.

But I guess that for deprecating things we should move the discussion 
onto the cocooon-dev list?


Kind regards,

Jeroen Reijn

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message