If you don't want to make the session contain the objects explicitly,
because the multistep process is only a small part of your
application, you could use session metadata to store the data
(temporarily). This does mean that it is serialized with the session,
but IMO that is a small price to pay (session in a single server
environment with low memory usage should not often be serialized, only
when the server is shutdown properly).

I haven't done multi window session storage yet, but that fails mostly
with detecting the different browser windows. Or you could generate a
unique number at the start of the wizard and use that to locate each
session object. But this could lead to significant memory leaks when
folks randomly start new wizard steps. You should limit the number of
concurrent wizards per session I think.

Martijn

On Thu, Aug 21, 2008 at 9:53 AM, John Patterson <[EMAIL PROTECTED]> wrote:
>
>
>
> Erik van Oosten wrote:
>>
>>
>>> The data is not serializable and is needed in several pages as a part of
>>> one transaction
>>
>> - Not serializable:
>> Well that is a hick up. This of course also means that you can not do
>> clustering. I would put the data directly in the HTTP session, or in
>> your own sub class of Wicket's WebSession. I think the page map is no
>> longer available (though perhaps that depends on the page store you
>> select).
>>
>
> The only problem with storing in the session is that there can only be one
> user transaction at a time.  It would be nice to allow separate tabs to be
> working on different items.  This is why I was asking about PageMap
>
> I remember some talk about renaming it to Window or something like that.
>
>
> Erik van Oosten wrote:
>>
>> - Part of one transaction.
>> Do you really mean like JTA transaction? Or are you talking about a
>> conversation (which was what I assumed).
>> Having multiple requests in one (JTA) transaction is not very common. I
>> guess if this is the case a reference to the transaction is part of your
>> non-serializable data.
>> If you did mean conversation/wizard kind of data, then the earlier
>> advice holds.
>>
>
> It is not a JTA transaction but a sequence of work on some objects that can
> be rolled back or committed.  These non serializable objects need to be
> stored in this "unit of work" over requests.
>
> No the earlier advice - to reference the data in the page - does not work
> for non-serializable objects.  I need to use some kind of detachable model
> to retrieve the modified data e.g. from session or pagemap.  Or to save its
> state between requests which would just be a bit inconvenient.
>
>
>
>
> --
> View this message in context: 
> http://www.nabble.com/Custom-PageMap-tp19073327p19084160.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to