You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Luther Baker <lu...@gmail.com> on 2009/06/11 13:26:45 UTC
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
Re: refresh page
Posted by Luther Baker <lu...@gmail.com>.
Ok, so that 'almost' wraps this up. HypbridUrlCodingStrategy works perfectly
for the Ajax-added data.
My last problem is related to the form fields. In
AjaxFallbackButton.onSubmit ... I clean out the input that holds the value
I've just added to the database and redisplayed in a list to the user. But,
on subsequent manual browser refresh, the INPUT that I wiped refreshes with
the user's LAST INPUT.
I don't mind this for the title, content or other input fields on the page -
but I don't want values showing up that I manually removed. I think this is
part of standard browser/form fields behavior.
I think Mike's approach would work here: ie: javascript that clears this
input out on load. I 'never' want any values in this input on load. I know
how to write an IHeaderContributor - is there something similar to add a
body=onload? If not, my specific page (Java/html) doesn't really create the
<body> tag ... what is the best way to grab it so that I can possibly add a
behavior that would create an onLoad handler.
Or, is there a better, wicket way to make sure this input is empty on
browser refresh?
Thanks,
-Luther
// add a category to the view
// and clean out input that supplied it
// dbase code intentionally left out
final AjaxFallbackButton addCategoryButton = new
AjaxFallbackButton("add-category", new ResourceModel("m-add-category"),
this)
{
private static final long serialVersionUID = 1L;
@Override
protected void onSubmit(final AjaxRequestTarget target,
final Form<?> form)
{
final IModel<String> model =
categoryCandidate.getModel();
final String text = model.getObject();
// make sure we should actually do something
if (text == null)
{
return;
}
// cleans out the form.INPUT
model.setObject(new String());
// add the new text to the categoriesModel (custom Set)
categoriesModel.add(text);
// redraw the form.INPUT
target.addComponent(categoryCandidate);
// redraw the <li> of categories
target.addComponent(categoriesParent);
}
};
To test the idea ... this works when placed in the markup after the input I
want to clean out:
<script type="text/javascript">
document.getElementById("category_candidate1e").value =
'';
</script>
But I can't leave this embedded in the HTML ... and I guess the ID can
change per wicket's whim. I need to add this to an body.onload event as a
behavior --- how to do I get ahold of the <body> element from within my
Page.java?
Re: refresh page
Posted by Luther Baker <lu...@gmail.com>.
>
> mount the page with hybridurlcodingstrategy and your problems will go away.
>
Flawless Victory!
Thanks everybody,
-Luther
Re: refresh page
Posted by Igor Vaynberg <ig...@gmail.com>.
sounds like ajax mods to a bookmarkable page...
mount the page with hybridurlcodingstrategy and your problems will go away.
-igor
On Thu, Jun 11, 2009 at 4:26 AM, Luther Baker<lu...@gmail.com> wrote:
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: refresh page
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hi Luther,
> 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.
>
>
There is a DOM event on 'unload' on the <body> tag that can be used to
notify the user about what will happen in this case; i.e. they will lose
the data they have entered if they refresh.
Have a look at ModalWindow since it implements an unload event for just
this case.
It seems like you should be able to add an AttributeModifier on the body
tag and then craft an interface where you particular component can
contribute a javascript callback to the main unload callback maybe via
an IModel<String>.
Another option if your forms are small enough is to just push an ajax
get request with customized parameters or
AjaxFormComponentUpdatingBehavior when the data is changed (i.e. bind
the callback to the 'onblur' event) This will populate the server side
models and allow a rerender to work properly.
Regards,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: refresh page
Posted by Nicolas Melendez <nm...@getsense.com.ar>.
Hi, i would use the Session, but also use it as a Context. Context should be
coded.
So you use the context in your page, and the context use the Session to
store data.
I don't think using the database is good idea.
NM
2009/6/11 Dorothée Giernoth <Do...@kds-kg.de>
>
> 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:lutherbaker@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 <lu...@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 <Do...@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:lutherbaker@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
AW: refresh page
Posted by Dorothée Giernoth <Do...@kds-kg.de>.
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:lutherbaker@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 <lu...@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 <Do...@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:lutherbaker@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: refresh page
Posted by Luther Baker <lu...@gmail.com>.
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 <lu...@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 <Do...@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:lutherbaker@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: refresh page
Posted by Luther Baker <lu...@gmail.com>.
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 <Do...@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:lutherbaker@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
AW: refresh page
Posted by Dorothée Giernoth <Do...@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:lutherbaker@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org