> > Can't you just let your controller remove those specific params?
> > Like:
> this.ControllerContext.Params.Remove(keythatidontwanttopropagate)
>
> This solves the problem, and you can do it automatically in your
> basecontroller class, if needed. I do not see any point so separate
> these namespaces.
This seems like a hack to me. It seems to me that the params were put into a
shared collection initially just to simplify things (in reality all the
Contexts are just references to MaverickContext). This little "cheating"
comment in TransformWithParams was always a little red flag to me that maybe
something undesired was going to come from this, but until it did, there was
no real reason to worry about it:
/**
* Sets some params before creating the step
*/
public TransformStep createStep(TransformContext tctx) throws
ServletException
{
// Ok, this is cheating a little
((MaverickContext)tctx).putAllParams(this.params);
return this.decorated.createStep(tctx);
}
Now we are beginning to see the repercussions and I think a refactoring is
worthwhile. I don't necessarily think it is fair to assume that Controller
params, View params, and Transform params are the same in ALL cases. Rather,
I think it makes more sense to completely separate them. Then instead of
removing the ones you don't want, add the ones you do to the other contexts.
--jim
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
[INVALID FOOTER]
