Re: [Webwork-devel] Sessionable Actions

[Rickard <ri...@xp...>]

Jason Carreira wrote:

> 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.


The problem is that the action is instantiated on the client with CSD. 
So, you have no way of intercepting it.

This might change in the future so that one may really call 
ActionFactory.getAction() even on the client, which would go to the 
server and get it (in order to perform prepare() properly). But then 
you'd send a lot of state back and forth three times for each action 
that is invoked.

I want the actions to be as shortlived and stateless *as possible*.

Are there any problems with having the action save the state in a 
session? Remember that it *can* (if it so chooses) store itself into a 
session, and then get it and use BeanUtil.copy to perform pretty much 
the same thing. The difference is that the framework doesn't have to 
know about it, or be changed to accomodate it.


> 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. 


I would perform this by having a generic action that can be used for 
these kinds of things instead. I.e. in your action that wants to save 
itself it would do:
StateAction state = (StateAction)ActionFactory.getAction(StateAction.class);
state.load(this, changeCount); // Copy stored action into this action
.. do things..
state.store(this); // Store action back into session, and have it 
increase changeCount

Then only StateAction would have to be SessionAware. The changeCount is 
incremented for each run, so that if double submitting is done the 
changeCount in load() is less then what is in the state store (=session) 
then the load fails, since another action has already "used" up the 
state of that changeCount(/timestamp).

> 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.


Hm.. this might be idealistic since there's often a difference between 
non-wizard and wizard mode in terms of process state changes and 
awareness. The above should work better, and also be possible to put in 
a base class, e.g.:

protected String doExecute()
{
StateAction state = (StateAction)ActionFactory.getAction(StateAction.class);
state.load(this, changeCount);
doWizard();
state.store(this);
}

Something like that. Now all you have to do is implement doWizard(), 
which in turn may delegate to methods for each wizard step.

This approach needs to be tested, but IMHO it will solve the same 
problem in a better way since it will not make actions themselves 
long-lived (which I really really want to avoid. Gut feeling tells me 
its the right thing to do).


> 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.

Hm.. what if the prepare() method did the check? Then it could barf at 
that point.

Also, if the action itself is not longlived, who cares if the setters 
are called? Big deal. It's thrown away anyway. :-)

/Rickard

-- 
Rickard Öberg