I dunno if I understand correctly, but how about constantly saving a
session-state user-specific in a database as soon as a component loses the
focus? If the site is refreshed, the session-id would be still valid and the
pre-refresh-session-state can be loaded?
After the user logs out correctly you can set a flag to true, to mark the
session as completed ... if for a reason the user is not logged out in a "yes,
I would like to leave and please save my changes"-way, this flag would not be
changed and saved for the user in the database. The user could reload the
session after he re-logs in as his changes are saved.
Dunno if that would be an acceptable approach or if that helps you at all.
- dg
-Ursprüngliche Nachricht-
Von: Luther Baker [mailto:lutherba...@gmail.com]
Gesendet: Donnerstag, 11. Juni 2009 15:22
An: users@wicket.apache.org
Betreff: Re: refresh page
So it turns out I'm going to want to display these values as a list ...
etc. My 'input' approach won't be adequate.
Back to the Session idea ... (smells already).
WIA has a security chapter that goes into storing a User in session - but
does anyone have a good resource that dives a bit deeper into best practices
with respect to Sessions? What about logical concepts/scopes like request,
flash, conversational, etc - and how wicket facilitates them?
Eg: I'd like to accumulate/remember page specific things while the user is
visits a particular url. Ideally, the transient info is dropped when the
user navigates away. I could create a POJO that represents the info and add
getters and setters to the wicket session object I extended from the WIA
security chapter ... but that smells bad. It seems heavy --- and I'm not
sure it makes sense to use that pattern everywhere I have Ajax buttons
putting rendering new values to the screen. Is there a more generalize
Wicket mechanism for this type of thing?
A localized, managed, short term, minimal, user specific, page specific type
of state management?
Or, given my issue, is there another way to think of this (out of box)?
Again, I am user's adding a few values (tags, categories) to the screen with
Ajax buttons and I need to make sure that information survives browser
behaviors like page refreshes.
Thanks,
-Luther
On Thu, Jun 11, 2009 at 7:07 AM, Luther Baker wrote:
> I think you're right - I would need to use the Session or the Database on
> each Ajax invocation to add these values.
>
> But it also seems that if I store the new, dynamic, page specific values
> into a TextField (as opposed to a div) - they survive a page refresh. I'm
> not sure if that is robust or formally a standard across all browsers - so I
> will do a bit more research but that seems to be the behavior I'm after.
>
> Thanks,
>
> -Luther
>
>
>
> 2009/6/11 Dorothée Giernoth
>
> Hmm, is that possible ... you can't like store session-data in the browser,
>> do you? You can only store session-details in the database on the fly with
>> ajax while the user still fills out the form to allow the user to re-create
>> the session on next login or something like this if he accidently hits
>> reload (but even then I am not sure if that works ... maybe if you write the
>> not yet submitted but in the form included information back into the fields
>> when the site is rendered) ...
>>
>> Does that make sense ... or I am not understanding the question ;)
>>
>> - dg
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Luther Baker [mailto:lutherba...@gmail.com]
>> Gesendet: Donnerstag, 11. Juni 2009 13:27
>> An: users@wicket.apache.org
>> Betreff: refresh page
>>
>> If I add a few values to a page > hits
>> refresh on the page, the new values I've added go away.
>>
>> The user is completing a form - but hasn't formally submitted the form yet
>> -
>> so there is nothing stored in the database yet. The browser naturally
>> re-renders the > content to any >
>> What would be the wicket way to allow these "dynamic divs" to survive a
>> page
>> refresh? Maybe on the a 'wicket-example'?
>>
>> Thanks,
>>
>> -Luther
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
