RE: [Webwork-devel] Sessionable Actions

[Jason C. <jas...@no...>]

> -----Original Message-----
> From: Rickard Oberg [mailto:ri...@xp...]
>
>
> Hm.. I'm not sure this is the way you'd want to do it. First of all I
> can see problems with this and the ClientServletDispatcher, where the
> action is being sent back and forth between clients and server. Second,
> why put the action itself into the session? Why not put a wizard object
> representation into the session? It should be simpler to just do that,
> and then extract it using a utility class, or a utility action.

This is really to skin the cat that ClientServletDispatcher also skins, i.e.
managing state and not having to send all of the params with each request.
In this case, don't save the Actions in the session. The
ClientServletDispatcher lets you keep the Action and use it multiple times,
just like this does, only in a different presentation type. I haven't looked
at ClientServletDispatcher except at the high level that you explained it,
so I don't know what the impact would be... Possibly instead of the
Sessionable Interface, it could be declarative in the action mapping as to
whether this particular action alias is saved in the session.

You've already got the Action, and it's already got the data from the form,
so why not use it? It also makes development much easier, because instead of
having to have your Action be session aware and save things into the
session, the Action itself is persisted in the session and available for the
next request. This makes Actions more reusable, since they aren't tied to
saving their data out into a session, so for instance, if you have the
Action being fed all by a huge one page form, you can very easily separate
this into multiple pages without having to implement the session state
saving with the wizard object.

>
> About double-submitting, that should be easily solved by using
> timestamps. I.e. in each form you include a number that is increased for
> each submit. In the action you compare the number received with the
> current number in the wizard object from the session. If its valid, then
> go ahead, but if its not, then return an error. That should always work.
>

This only works with the synchronization I mentioned. Otherwise, you could
have the setters being called during the execution of the Action from a
previous request, since it's multithreaded.

Jason