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.
I'm not saying you don't have a good use case for not doing redirects
between action and render but unless you have a reason beyond not
wanting to do the 302 I would say it is much more work than it is worth.
-Eric
David H. DeWolf wrote:
Pawel Kozlowski wrote:
Hi,
I'm working at the simple portal framework based on Pluto (1.1-beta
currently). Unfortunately, I've run into issue PLUTO-124.
So, I've got 2 questions:
1) Is there any chance that this issue would be fixed anytime
soon? Of
course I can help with this one.
The best bet for getting this enhancement asap would be to submit a
patch. Otherwise, you're at the mercy of the committers to feel as
though it's important enough :)
I still don't really understand why this is needed. Are you
converting all of the post data into render parameters and the render
parameter string blows the url buffer? Is that the issue?
2) I wonder if, while fixing PLUTO-124, it would be possible to
have a
pluggable strategy fragment sending a redirection after processing an
action request (class PortletContainerImpl, method doAction)?
Currently, this implementation will always send a HTTP redirect and it
is impossible to create a portal implementation that would process an
action and a render request in one HTTP request. As fare I know, this
model of portal request processing is not forbidden by JSR-168?
No, it's not forbidden BUT it's also not impossible with the current
implementation. Remember that the request/response provided to the
container can be wrapped by the webapp/portal embedding the container
to intercept any of the method calls.
Additionally the url provider could store request parameter state in
the session as opposed to parameters. Take a look at the sakai
charon velocity branch as an example if you're looking for an impl
that will do that.
So, basically, I would like you to tell me if you think it is possible
to address the issues described. If you could provide me with some
starting points / directions I could play with the code a little bit.
It's possible, but since there are work arounds, it's not on my
"high" priority list. That said, if you submit a patch for an
enhancement, I'll at least take a look at it and commit if I think it
makes sense. Feel free to ping ideas off the list before you code it
up and I'll do my best to comment.
David
Brgds,
Pawel Kozlowski
