> > > > Something broke my request object!
> > > >
> > > > I just upgraded to the latest CVS.
> > > > And I cannot get any request parameters
> > > > anymore. I use CA a lot.
> > > >
> > > > Carsten, maybe your last CA fixes have
> > > > undesired side effects? I'll have a
> > > > deeper look into this one...
> > >
> > > Yes, actually my changes for making the cocoon:// url work,
> > > did break this.
> > > The aggregated parts now do not get the original parameters
> > > from the request but they have one parameters, so you can
> > > write cocoon:/mypart?parameter=value.
> > >
> > > This is very important to give new and different parameters
> > > to the aggregated pipelines. I think this is a useful
> > > feature.
> > >
> > > For your problem there are two solutions:
> > > 1. You "copy" the parameters to the parts
> > > or
> > > 2. The parts get (inherit) the paramters from the original request
> > > and can add their own
> > >
> > > Perhaps we should do the second approach?
> >
> > Eeek... I don't know if I like this at all!
> >
> > I need the original request object in an
> > action. I don't know how many parameters
> > there will be... IMHO copying in general
> > is bad idea! But how would you propose
> > to do the inheriting? Keep in mind that
> > the action has no idea if it is inside the
> > aggregated part or not!
> You get the RequestWrapper object which wrappes the original
> request. It delivers (passes through) the same information
> like the original request except the parameters.
>
> I am just fixing this that the request inherites the
> parameters, so if you pass no additional paramters to the
> aggregated url, you have exactly the same behaviour
> without noticing it (I hope at least so).
And what about merging it like the substitution map in
the sitemap? (the flexibility syndrom ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
