Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Maurice Marrink
Hmm, i'm not sure this will work at all with the restartresponse but i
have 2 alternatives that do not require changes to wicket

-append some javascript to the ajaxrequesttarget that will trigger the
browser to request your login page (you can get the wicket url for the
loginpage using urlFor)
 if your login page accepts pageparams you can use those to decide
what the response for a successful login should be.

-open you login page in a ModalWindow on the same page and close it
after a successful login (you might need to refresh the origin page
after this)

Maurice

On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:

  Hi,

  I'm currently trying to use RestartResponseAtInterceptPageException with
  Ajax. More precisely, I show a component that refreshes itself after
  executing an authorized action. It the user is not authorized to execute
  this action, I'd like to redirect him to the Login-Page. After proper login,
  the user should be redirected to the original page. However, using
  continueToOriginalDestination() does not work (out of the box), as the User
  is redirected to the URL of the Ajax request.


  Workaround/Possible changes to simplify workaround:

  A custom workaround would be to do a custom PageMap implementation. However,
  as the method setUpRedirect(RequestCycle) is private, deriving from the
  default PageMap will require some ugly copy-paste in order to do so. This
  could be avoided by a) making setUpRedirect(RequestCycle) protected and/or
  b) introduce a protected method that constructs the interceptContinuationURL
  inside setUpRedirect(RequestCycle).


  Changing default behaviour:

  The workaround version is not trivial, as in requires quite a bit of
  knowledge of Wicket's inner workings (What the hell is a PageMap?).
  Therefore, it might be a good idea to change the default behaviour there, as
  no user wants to see Ajax responses at all (well, at least no normal user -
  I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
  somewhat more intelligent by default (without hacking a custom PageMap)?
  That is to redirect to the page the Ajax request belonged to? Or even
  better: redirect to the Ajax call and render the complete page (well, don't
  know how tricky that would be).

  Or do I miss something completely? Any other possible workarounds or
  suggestions?

  Cheers, Stefan

  -
  ---
  Stefan Fußenegger
  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
  --
  View this message in context: 
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

Hi,

I'm currently trying to use RestartResponseAtInterceptPageException with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to execute
this action, I'd like to redirect him to the Login-Page. After proper login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as the User
is redirected to the URL of the Ajax request.


Workaround/Possible changes to simplify workaround:

A custom workaround would be to do a custom PageMap implementation. However,
as the method setUpRedirect(RequestCycle) is private, deriving from the
default PageMap will require some ugly copy-paste in order to do so. This
could be avoided by a) making setUpRedirect(RequestCycle) protected and/or
b) introduce a protected method that constructs the interceptContinuationURL
inside setUpRedirect(RequestCycle).


Changing default behaviour:

The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a PageMap?).
Therefore, it might be a good idea to change the default behaviour there, as
no user wants to see Ajax responses at all (well, at least no normal user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
somewhat more intelligent by default (without hacking a custom PageMap)?
That is to redirect to the page the Ajax request belonged to? Or even
better: redirect to the Ajax call and render the complete page (well, don't
know how tricky that would be).

Or do I miss something completely? Any other possible workarounds or
suggestions?

Cheers, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]



Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

Maurice, 

Thanks for your suggestions. However, these suggestions are yet 2 other
workarounds for this problem.

imho, using RestartResponseAtInterceptPageException and
continueToOriginalDestination() should work out of the box, regardless of
the type of request (Ajax and non-Ajax). Therefore I suggest adding support
to the framework - and your suggestions did not convince me not to do so,
sorry ;)

However, the strategy to choose a page for continueToOriginalDestination()
is open for discussion. The simplest approach would be to go back to the
source of the Ajax request, while allowing to complete the request and
render the entire page afterwards would be best.

-- Stefan



Mr Mean wrote:
 
 Hmm, i'm not sure this will work at all with the restartresponse but i
 have 2 alternatives that do not require changes to wicket
 
 -append some javascript to the ajaxrequesttarget that will trigger the
 browser to request your login page (you can get the wicket url for the
 loginpage using urlFor)
  if your login page accepts pageparams you can use those to decide
 what the response for a successful login should be.
 
 -open you login page in a ModalWindow on the same page and close it
 after a successful login (you might need to refresh the origin page
 after this)
 
 Maurice
 
 On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

  Hi,

  I'm currently trying to use RestartResponseAtInterceptPageException with
  Ajax. More precisely, I show a component that refreshes itself after
  executing an authorized action. It the user is not authorized to execute
  this action, I'd like to redirect him to the Login-Page. After proper
 login,
  the user should be redirected to the original page. However, using
  continueToOriginalDestination() does not work (out of the box), as the
 User
  is redirected to the URL of the Ajax request.


  Workaround/Possible changes to simplify workaround:

  A custom workaround would be to do a custom PageMap implementation.
 However,
  as the method setUpRedirect(RequestCycle) is private, deriving from the
  default PageMap will require some ugly copy-paste in order to do so.
 This
  could be avoided by a) making setUpRedirect(RequestCycle) protected
 and/or
  b) introduce a protected method that constructs the
 interceptContinuationURL
  inside setUpRedirect(RequestCycle).


  Changing default behaviour:

  The workaround version is not trivial, as in requires quite a bit of
  knowledge of Wicket's inner workings (What the hell is a PageMap?).
  Therefore, it might be a good idea to change the default behaviour
 there, as
  no user wants to see Ajax responses at all (well, at least no normal
 user -
  I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
  somewhat more intelligent by default (without hacking a custom PageMap)?
  That is to redirect to the page the Ajax request belonged to? Or even
  better: redirect to the Ajax call and render the complete page (well,
 don't
  know how tricky that would be).

  Or do I miss something completely? Any other possible workarounds or
  suggestions?

  Cheers, Stefan

  -
  ---
  Stefan Fußenegger
  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
  --
  View this message in context:
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]



Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Igor Vaynberg
feel free to add a jira request for this

-igor


On Thu, Feb 21, 2008 at 4:44 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:

  Maurice,

  Thanks for your suggestions. However, these suggestions are yet 2 other
  workarounds for this problem.

  imho, using RestartResponseAtInterceptPageException and
  continueToOriginalDestination() should work out of the box, regardless of
  the type of request (Ajax and non-Ajax). Therefore I suggest adding support
  to the framework - and your suggestions did not convince me not to do so,
  sorry ;)

  However, the strategy to choose a page for continueToOriginalDestination()
  is open for discussion. The simplest approach would be to go back to the
  source of the Ajax request, while allowing to complete the request and
  render the entire page afterwards would be best.

  -- Stefan





  Mr Mean wrote:
  
   Hmm, i'm not sure this will work at all with the restartresponse but i
   have 2 alternatives that do not require changes to wicket
  
   -append some javascript to the ajaxrequesttarget that will trigger the
   browser to request your login page (you can get the wicket url for the
   loginpage using urlFor)
if your login page accepts pageparams you can use those to decide
   what the response for a successful login should be.
  
   -open you login page in a ModalWindow on the same page and close it
   after a successful login (you might need to refresh the origin page
   after this)
  
   Maurice
  
   On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
   [EMAIL PROTECTED] wrote:
  
Hi,
  
I'm currently trying to use RestartResponseAtInterceptPageException with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to execute
this action, I'd like to redirect him to the Login-Page. After proper
   login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as the
   User
is redirected to the URL of the Ajax request.
  
  
Workaround/Possible changes to simplify workaround:
  
A custom workaround would be to do a custom PageMap implementation.
   However,
as the method setUpRedirect(RequestCycle) is private, deriving from the
default PageMap will require some ugly copy-paste in order to do so.
   This
could be avoided by a) making setUpRedirect(RequestCycle) protected
   and/or
b) introduce a protected method that constructs the
   interceptContinuationURL
inside setUpRedirect(RequestCycle).
  
  
Changing default behaviour:
  
The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a PageMap?).
Therefore, it might be a good idea to change the default behaviour
   there, as
no user wants to see Ajax responses at all (well, at least no normal
   user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
somewhat more intelligent by default (without hacking a custom PageMap)?
That is to redirect to the page the Ajax request belonged to? Or even
better: redirect to the Ajax call and render the complete page (well,
   don't
know how tricky that would be).
  
Or do I miss something completely? Any other possible workarounds or
suggestions?
  
Cheers, Stefan
  
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
   
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  


  -
  ---
  Stefan Fußenegger
  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
  --
  View this message in context: 
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

I was just waiting for green lights ;)

https://issues.apache.org/jira/browse/WICKET-1363


igor.vaynberg wrote:
 
 feel free to add a jira request for this
 
 -igor
 
 
 On Thu, Feb 21, 2008 at 4:44 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

  Maurice,

  Thanks for your suggestions. However, these suggestions are yet 2 other
  workarounds for this problem.

  imho, using RestartResponseAtInterceptPageException and
  continueToOriginalDestination() should work out of the box, regardless
 of
  the type of request (Ajax and non-Ajax). Therefore I suggest adding
 support
  to the framework - and your suggestions did not convince me not to do
 so,
  sorry ;)

  However, the strategy to choose a page for
 continueToOriginalDestination()
  is open for discussion. The simplest approach would be to go back to the
  source of the Ajax request, while allowing to complete the request and
  render the entire page afterwards would be best.

  -- Stefan





  Mr Mean wrote:
  
   Hmm, i'm not sure this will work at all with the restartresponse but i
   have 2 alternatives that do not require changes to wicket
  
   -append some javascript to the ajaxrequesttarget that will trigger the
   browser to request your login page (you can get the wicket url for the
   loginpage using urlFor)
if your login page accepts pageparams you can use those to decide
   what the response for a successful login should be.
  
   -open you login page in a ModalWindow on the same page and close it
   after a successful login (you might need to refresh the origin page
   after this)
  
   Maurice
  
   On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
   [EMAIL PROTECTED] wrote:
  
Hi,
  
I'm currently trying to use RestartResponseAtInterceptPageException
 with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to
 execute
this action, I'd like to redirect him to the Login-Page. After
 proper
   login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as
 the
   User
is redirected to the URL of the Ajax request.
  
  
Workaround/Possible changes to simplify workaround:
  
A custom workaround would be to do a custom PageMap implementation.
   However,
as the method setUpRedirect(RequestCycle) is private, deriving from
 the
default PageMap will require some ugly copy-paste in order to do so.
   This
could be avoided by a) making setUpRedirect(RequestCycle) protected
   and/or
b) introduce a protected method that constructs the
   interceptContinuationURL
inside setUpRedirect(RequestCycle).
  
  
Changing default behaviour:
  
The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a
 PageMap?).
Therefore, it might be a good idea to change the default behaviour
   there, as
no user wants to see Ajax responses at all (well, at least no normal
   user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour
 be
somewhat more intelligent by default (without hacking a custom
 PageMap)?
That is to redirect to the page the Ajax request belonged to? Or
 even
better: redirect to the Ajax call and render the complete page
 (well,
   don't
know how tricky that would be).
  
Or do I miss something completely? Any other possible workarounds or
suggestions?
  
Cheers, Stefan
  
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
  
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  


  -
  ---
  Stefan Fußenegger
  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
  --
  View this message in context:
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer