Rick Reumann wrote:
Well speaking of MyFaces/JSF again, I did something like x:saveState on the session side.Michael Jouravlev wrote the following on 7/28/2005 4:30 PM:Ahem, actually I am all in for sessions. I just don't see why it storing stuff in an action form with session scope is universally frowned upon, while sticking same stuff directly into session is OK ;-)Most seem to frown on both scenarios. Personally, I like the Session:) The concept of the "session cleanup" tool has been talked about so many times on this list, but I've yet to see an easy implementation of it. For me, I'd rather use the Session until some manager starts complaining that the app has performance issues (and even then I'd probably add more RAM vs throw away my reliance on the Session:)
x:saveState itself is very easy to use x:saveState name="#{dataobject}" in a form means that the object is serialized
if you run into the x:saveState name="#{dataObject}" in the next form
the object is basically recycled before the incoming values are applied
and so on, the first time you hit a page without x:saveState
name="#{dataobject}" the object is garbage collected.
http://wiki.apache.org/myfaces/SaveStateIt does not get easier. All the implementations of dialog systems with their dedicated dialog configs in the configuration files are way more complex than that and do not achieve significantly more, expect pushing the system into the config files (which in many cases is not needed, especially not for wizards).
Having such a mechanism in struts would ease things tremendously.
For a wizard like Werner initially described, I'd use a Session based form in a heart-beat. I use session scoped forms and they work wonderfully.I am not against sessions otherwise I would not have implemented an x:saveState on a session base once, in fact I prefer sessions to plain serialisation for many reasons, (for those who are familiar with jsf, the code is on jsf-comp on sourceforge), the problems with sessions is just, that you have to garbage collect the objects from the session manually, and that is rather error prone, especially once you hit unexpected conditions.
With a handful of users, stuffing everthing into sessions works wonderfully but with a few hundred or thousand, it does not anymore, that is unfortunately the main problem, so you dump the data out of the session regularily.
But for my current project I probably will use a dialog system and check how it works out (Spring Dialog probably would be the perfect choice, since I use Spring anyway, for the business and data layer)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
