The point of this reply is that you'd want to ensure that your setup command gets called as part of the render() lifecycle, so that you can do the setup stuff even if your portlet wasn't the one that processed this request's form values. It might even mean some thought should be put into separating "the" request processing chain into two chains, so that you can simulate the same thing for Tiles-based apps (including supporting the Tiles Controller interface, which serves the same "render setup" purpose).
Thanks. I have not had much chance to get up to speed with portlets. Separating the chain into two is fundamental to my current vision, so that the "main" context can be wrapped in API-independent ActionContext/ViewContext classes. So I think that one could use the same base chains but with a "portlet-complete" variant instead of a "servlet-complete", which would address the differences. I'd love to produce something which is Portlet friendly, but I'm not going to drop everything to learn all about Portlets to do it, since I have no plans to be using Portlets.
I think the TilesPreProcessor class should end up causing all tiles controllers to be invoked, since it's only a light wrapper around the behavior from the TilesRequestProcessor. In fact, although I don't use Tiles controllers extensively, I do know that I have some in my current app which work correctly using the TilesPreProcessor command, even with a singular request processing chain.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
