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 ul ...
li 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 lutherba...@gmail.com 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 dorothee.giern...@kds-kg.de
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 div ala an Ajax button - and the user
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 textarea and input values to the screen - but wipes out
content to any divs I might have dynamically added data to.
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
