Hi Uwe,
Thanks for your reply, I understand your technique now. However, what
about when we do care about URLs? For example, my LoginPageLink class is as
follows:
@NonAuthOnly
private final class LoginPageLink extends BookmarkablePageLink {
private static final long serialVersionUID = 1L;
public LoginPageLink(String id) {
super(id, LoginPage.class);
}
// @Override
// public void onClick() {
// LoginPage lp = new LoginPage();
// lp.setReferringPage(BasePage.this.getPage());
// }
}
Not really quite sure how to create an instance of LoginPage here and still
being able to use BookmarkablePageLink...
using Link produces nasty href URLs which I don't want on my public-facing
home page.
The only solution I can come up with now is to use some Link derivative and
create the static URL which will be used in the href to make it look nice
while being able to override onClick()...
Uwe Schäfer wrote:
>
> classacts schrieb:
>
>> When I'm at AppPage {"1=foo"} and click on the Login link, I then go to
>> the
>> LoginPage with a nice URL showing in the address bar. After submitting
>> the
>> login form and upon successful authentication, I want to automatically
>> navigate back to AppPage {"1=foo"} so that it is re-rendered to take into
>> account he user is now authenticated and consequently has more authority.
>
> so if not using RestartResponseAtInterceptionPage, what you want is to
> a) move to a nice looking/bookmarkable url for that login page and
> b) pass the reference to your current page, so that the targeting page
> can do setResponsePage(myBackPage);
>
> this can be complished using HybridUrlCodingStrategy like below.
>
>> At first glance, it seems that your solution would work the best as you
>> have
>> the ability to store information in the MetaData portion of the
>> components.
>
> well it is more about passing data directly to the targeted page, but
> STILL have a nicelooking and bookmarkable URL.
>
> Let´s say you would not care about URLs, what you´d do is:
>
> class A extend Page{
> ...
> B b = new B();
> b.setWhateverStateYouLike(..);
> b.setMybackPage(this);
> setResponsePage(b);
> ...
> }
>
> class B extends Page {
> ...
> setMyBackPage(Page back){this.back=back;}
> ...
> new Link("back"){
> void onClick(){
> setResponsePage(back);
> }
> }
> ...
> }
>
> the 'problem' here is - for those, who care about urls - the URL you
> give to B here does not have parameters.
>
> with the mentioned
>
> b.setMetaData(HybridUrlCodingStrategy.PAGE_PARAMETERS_META_DATA_KEY,
> new PageParameters(...))
>
> you could add parameters to the URL. That is it.
>
>>>> Basically, Page targetPage = new LoginPage(new PageParameters());
>>>> (LoginPage doesn't have any parameters)
>> Page targetPage = new BookmarkablePageClass(...
>
> well, you don´t need parameters then ;)
>
>> By following the above implementation, would it not be a tad wasteful
>> creating LoginPage instances every time any BasePage sibling is created?
>
> sure, why would you want to do that?
>
> what about
>
> new Link("bla"){onClick(){setResponsePage(new LoginPage(...);}} ?
> you´d create it when it is needed then, right?
>
> cu uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Going-back-to-a-previous-URL--tp19254601p19267162.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]
