Stefan Hepper <[EMAIL PROTECTED]> wrote on 15/02/2007 09:34:22: > Right, you would need some kind of action ID in each action URL and > check if that action was already executed or not. > > Stefan > > Eric Dalquist wrote: > > My 2 cents on this issue: > > > > At one point in the past uPortal 2.4 had overridden the redirect > > behavior using pluto 1.0 We ditched this after running into numerous > > spec compliance issues that were much easier to resolve by using > > redirects. Much of it had to do with ensuring actions only occurred > > once, making the back & forward buttons functional, dealing with an > > actions ability to change the state/mode send redirects and such.
Hi Stefan, Eric, Unfortunately, I've got a "valid use case": I'm planning to use Pluto + Spring Web Flow + existing MVC controllers. The problem is that shoes controllers were written before the redirect-after-post movement. Those controllers are putting their results in a HTTP request and rewriting those controllers is not an option?. But, going back to your comment regarding action ids ? I'm afraid I can't see the problem? Could you elaborate more? I was envisioning an implementation in which the portal framework is reading a configuration of a page (all the portlet / portlet windows on the given page) and: if this is an action request (action parameter = true and valid portlet window id in the URL), execute an action request against for the specified portlet window id execute render request against all the portlets on the page In case of the render request coming to the portal I would simply execute render request against all the portlets on the page So, for me, for each HTTP request that would be an exactly one action request and several render requests. So, that is why I'm puzzled by action ids in the urls? Sorry if I'm asking obvious questions, but my experience with porltlet containers / Pluto is next to nothing, compared to yours? Would be really grateful for more explanations? Brgds, Pawel
