Try this
I have this method for getting the current page id and version.
protected PageIDVersion getCurrentPageIDVersion() {
PageIDVersion pageIDVersion = new
PageIDVersion(getPageMapEntry().getNumericId(), getCurrentVersionNumber());
return pageIDVersion;
}
I send it to the next page by using a
class PageIDVersion {
private Integer pageNum;
private Integer version;
}
I store it as an instance in next page.
public class NextPage() {
private pageIdVersion pageIdVersion
private NextPage(PageIDVersion pageIdVersion) }
this.pageIdVersion = pageIDversion;
}
}
Then use this button to reference the previous page.
package com.ccti.base.web.components.button;
import org.apache.wicket.behavior.SimpleAttributeModifier;
import org.apache.wicket.markup.html.link.Link;
import com.ccti.base.web.utilities.PageIDVersion;
/**
* @author Carlo M. Camerino
*
*/
public class BackButton extends Link {
private PageIDVersion pageIDVersion;
public BackButton(String id, PageIDVersion pageIDVersion) {
super(id);
this.pageIDVersion = pageIDVersion;
add(new SimpleAttributeModifier("value", "Back"));
}
@Override
public void onClick() {
setResponsePage(getPage().getPageMap().get(pageIDVersion.getId(),
pageIDVersion.getVersion()));
}
}
On Mon, Apr 27, 2009 at 10:44 PM, James Carman <jcar...@carmanconsulting.com
> wrote:
> Copy/paste the code for PageReference into your code. That's what I
> did. I also created a factory method to create a PageReference from
> the currently requested page (useful for being able to go back).
>
> On Mon, Apr 27, 2009 at 10:42 AM, Daniele Dellafiore <ilde...@gmail.com>
> wrote:
> > I have tried to find something but, given that I am using wikcket 1.3
> > and I do not have PageReferences, the only way I have found to recover
> > the last page is to pass a parameter with the page name and then found
> > the last version of that page in the HttpSession pageMap.
> > Or to keep the reference of the last page in the session.
> >
> > I can do it but I expect that wicket already have that kind of
> > mechanism. Doesn't it?
> >
> > On Tue, Apr 14, 2009 at 8:30 PM, Igor Vaynberg <igor.vaynb...@gmail.com>
> wrote:
> >> search this forum for pagereference
> >>
> >> -igor
> >>
> >> On Tue, Apr 14, 2009 at 9:28 AM, Daniele Dellafiore <ilde...@gmail.com>
> wrote:
> >>> Here is my "return to last page" problem.
> >>>
> >>> A "detail" page has multiple tabs, an AjaxTabbedPanel. Swithing
> >>> between tabs does not put another page in browser history, so
> >>> history.back() is fine.
> >>> I have also a checkbox that trigger enable/disable state of all the
> >>> input of the form. Is an AjaxCheckBox that in the callback refresh the
> >>> form component after changing the "enable" property. The
> >>> history.back() works, again.
> >>>
> >>> But, I have a "reset" button that:
> >>> 1. reload the old values in the fields
> >>> 2. put the form in a disable state, like at the beginning.
> >>>
> >>> Now, to achieve this result, the Reset button actually calls a
> >>> setResponsePage(getPage(), getPage().getPageParameters())
> >>>
> >>> so reloads the current page with original parameters.
> >>> That calls actually make the history grow, so the history.back() is no
> >>> longer useful becouse, in fact, goes to the last version of the actual
> >>> page instead of the previous page.
> >>>
> >>> Any suggestion?
> >>>
> >>> I should simply use a document.form.reset() making that the Reset
> >>> button is not a submit button... sounds fine?
> >>>
> >>> In general, what is the best solution "wicket-like"? Is something
> >>> REST-like a la gmail, that returns to the /search/myFilter ? Or
> >>> something statefull, so I suppose it should be easy to recover the
> >>> last rendered page with the right version and so on...
> >>>
> >>> On Fri, Mar 13, 2009 at 5:18 PM, francisco treacy
> >>> <francisco.tre...@gmail.com> wrote:
> >>>> igor, i would agree with you if i wanted to mimic the browser back
> >>>> button functionality.
> >>>>
> >>>> but i do not. we intensively use panel swapping and we're only
> >>>> interested in registering when users click on certain pages (we can
> >>>> fine-tune pages which pages should be "back-clickable").
> >>>>
> >>>> we actually considered using history.go(-1), but if you want your app
> >>>> to seriously take into account usability / user experience, it's
> >>>> useless -- for instance think panel swapping, or rendering links such
> >>>> as "back to your search for ice-cream". personally i'm not someone who
> >>>> likes complexity just for the sake of it.
> >>>>
> >>>> francisco
> >>>>
> >>>>
> >>>> On Fri, Mar 13, 2009 at 3:43 PM, Igor Vaynberg <
> igor.vaynb...@gmail.com> wrote:
> >>>>> its really a lot of work to duplicate what the back button in the
> >>>>> browser already does. or a simple <a href="#"
> >>>>> onclick="history.go(-1)">back</a> will do as well.
> >>>>>
> >>>>> -igor
> >>>>>
> >>>>> On Fri, Mar 13, 2009 at 5:02 AM, francisco treacy
> >>>>> <francisco.tre...@gmail.com> wrote:
> >>>>>> to be honest i haven't read the whole thread, but we are also trying
> >>>>>> to achieve roughly the same thing.
> >>>>>>
> >>>>>> as of wicket 1.4-m1 there is a class called PageId that you may want
> >>>>>> to consider.
> >>>>>>
> >>>>>> i created a "back state holder" class that holds a PageId and an
> >>>>>> IModel<String> for the text of the back link. so for every visited
> >>>>>> page (in the onBeforeRender - could be placed in the base page), we
> >>>>>> set a holder in the session and in our base page we call
> >>>>>> Session.get.getHolder. pretty simple really.
> >>>>>> as the PageId class is a unique identifier of the page you can use
> it
> >>>>>> to distinguish between pagemaps, etc. (so navigation doesn't
> interfere
> >>>>>> between tabs / windows)
> >>>>>>
> >>>>>> this fulfills our usecase, as this is just a helper link to "go back
> >>>>>> where you were". we don't completely rely on this link because we
> also
> >>>>>> do keep traditional navigation links in our pages.
> >>>>>>
> >>>>>> however i still need to solve the double click problem, i.e. if a
> user
> >>>>>> clicks twice on a link, the last rendered page will be the same as
> the
> >>>>>> one he is in. thus, the back link points to the same page. it is
> >>>>>> actually quite tricky to get it right, yet i believe possible. i
> will
> >>>>>> definitely try to avoid the link handing over pageparams in the url
> >>>>>> "like in the good old days" :)
> >>>>>>
> >>>>>> i will post it once i get everything working together.
> >>>>>>
> >>>>>> francisco
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Mar 13, 2009 at 10:29 AM, pixologe <pixol...@mailinator.com>
> wrote:
> >>>>>>>
> >>>>>>> Just a thought which I did not think about when implementing this
> (thus I had
> >>>>>>> to change this stuff all over afterwards), perhaps it helps someone
> avoiding
> >>>>>>> the same mistake:
> >>>>>>>
> >>>>>>> The latest rendered page is not neccessarily the page that lead the
> user to
> >>>>>>> the current page.
> >>>>>>> I.e. retrieving the last page this way might result in strange
> behavior if
> >>>>>>> the user uses two browser windows or tabs simulaneously. Same
> applies for
> >>>>>>> clicking the browser's back button.
> >>>>>>>
> >>>>>>> Thus I had to go back to a rather old-fashioned solution, where
> every link
> >>>>>>> hands over a page param :-/ like in the good old days ;-)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> rolandpeng wrote:
> >>>>>>>>
> >>>>>>>> great! after delare a ineer class below:
> >>>>>>>> class PageIdVersion {
> >>>>>>>> public int id;
> >>>>>>>> public int version;
> >>>>>>>> public PageIdVersion last;
> >>>>>>>> }
> >>>>>>>> then the track function works.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> John Patterson wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> // must declare hash map because meta data must be
> serializable
> >>>>>>>>> private MetaDataKey<HashMap<String, PageIdVersion>>
> lastPageIdVersionKey
> >>>>>>>>> = new MetaDataKey<HashMap<String, PageIdVersion>>() {};
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> View this message in context:
> http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p22492628.html
> >>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Daniele Dellafiore
> >>> http://blog.ildella.net/
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Daniele Dellafiore
> > http://blog.ildella.net/
> >
> > ---------------------------------------------------------------------
> > 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
>
>
