Re: [Wicket-user] Wicket and web services

2007-05-14 Thread Johan Compagner

you should do a redirect.

Because if i do a refresh of the browser with the form url in it
i think think the browser ask me do you want to resubmit it (and i guess
that is a post again??)

johan

On 5/14/07, Lowell Kirsh [EMAIL PROTECTED] wrote:


Hi, I'm not sure I understand what you just said. I think I do have
the url of the post in my browser. That is, now that I have set
redirect=false, when you reload the results page, it will execute the
logic (with side effects) again. But I'm thinking perhaps I'm doing
this wrong.

Basically, I have a form and a results page. The way I have it now is
that during the rendering of the results page, the side-effect-having
logic gets executed. But I just realized another way of doing this
would be to have that logic execute in the form page, and then pass
the results of that to the results page. In general, when you have a
form and a results page, do you want to put the side effect logic (eg.
a database insert) in the form page or in the results page?

On 5/13/07, Johan Compagner [EMAIL PROTECTED] wrote:
 but you don't submit again because in the browser you never
 have the url of the post (at least in the default settings of wicket)
 because then we always do a redirect after post

 johan



  On 5/12/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
   why would you test for post in the resulting page?
 
  The page has side effects, so if you are viewing it in your browser
  and press refresh, it should not execute again. Or at least, there
  should be a warning before submitting.
 
  I think my best bet is to not try to overload the functionality of
  this page. I will probably create another page for programmatic
  access.
 
   A form will be submitted to a page. (that will be done in a page and
 then
   method should be post)
   then a redirect will happen to a page that you set as a result page
(or
 it
   is the same)
   and that page will not be in a post but will be in a get
  
   but how do you set the result page?
   you can try setRedirect(false) after you set the result page.
  
   How is your webservice access your page? that does the post to the
form?
   But then you are in the submit and you know you are ok.
  
   johan
  
  
  
   On 5/11/07, Lowell Kirsh [EMAIL PROTECTED]  wrote:
   
I want some of my pages to be accessed programatically. Basically,
that page may be accessed as a 'web service'. So the same page may
be
arrived at in 2 ways - the result of a form submission from
another
page in the same app, or the result of a direct http connection.
When
accessed as a web service, there are a few extra requirements -
the
page must be POSTed to, and there must be an extra http request
header
for authorization.
   
I was thinking that the page could make sure that it always is
POSTed
to, but when arrived at in the context of a form submission in the
application, it apparently ends up being the result of a redirect
after the form post, so the page does not think it was posted to.
So I
think perhaps the page should only ensure it was posted to if it's
from outside the application. Is there a way for the page to know
that
its referrer is another page in the same application? Check the
referrer header?
   
Is trying to overload this page like this crazy? I thought it
would be
less work and a cleaner design, but am not sure when I should just
give up.
   
Lowell
   
   
  

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
  

-
   This SF.net email is sponsored by DB2 Express
   Download DB2 Express C - the FREE version of DB2 express and take
   control of your XML. No limits. Just data. Click to get it now.
   http://sourceforge.net/powerbar/db2/
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
 
 

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and take
  control of your XML. No limits. Just data. Click to get it now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 



-
 This SF.net 

Re: [Wicket-user] Wicket and web services

2007-05-14 Thread Lowell Kirsh
But I want the browser to ask that, because a re-post is dangerous.
Perhpas the dangerous logic should be in the submission page instead
of the results page.

On 5/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
 you should do a redirect.

 Because if i do a refresh of the browser with the form url in it
 i think think the browser ask me do you want to resubmit it (and i guess
 that is a post again??)

 johan


  On 5/14/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
  Hi, I'm not sure I understand what you just said. I think I do have
  the url of the post in my browser. That is, now that I have set
  redirect=false, when you reload the results page, it will execute the
  logic (with side effects) again. But I'm thinking perhaps I'm doing
  this wrong.
 
  Basically, I have a form and a results page. The way I have it now is
  that during the rendering of the results page, the side-effect-having
  logic gets executed. But I just realized another way of doing this
  would be to have that logic execute in the form page, and then pass
  the results of that to the results page. In general, when you have a
  form and a results page, do you want to put the side effect logic (eg.
  a database insert) in the form page or in the results page?
 
  On 5/13/07, Johan Compagner [EMAIL PROTECTED] wrote:
   but you don't submit again because in the browser you never
   have the url of the post (at least in the default settings of wicket)
   because then we always do a redirect after post
  
   johan
  
  
  
On 5/12/07, Lowell Kirsh  [EMAIL PROTECTED] wrote:
 why would you test for post in the resulting page?
   
The page has side effects, so if you are viewing it in your browser
and press refresh, it should not execute again. Or at least, there
should be a warning before submitting.
   
I think my best bet is to not try to overload the functionality of
this page. I will probably create another page for programmatic
access.
   
 A form will be submitted to a page. (that will be done in a page and
   then
 method should be post)
 then a redirect will happen to a page that you set as a result page
 (or
   it
 is the same)
 and that page will not be in a post but will be in a get

 but how do you set the result page?
 you can try setRedirect(false) after you set the result page.

 How is your webservice access your page? that does the post to the
 form?
 But then you are in the submit and you know you are ok.

 johan



 On 5/11/07, Lowell Kirsh [EMAIL PROTECTED]  wrote:
 
  I want some of my pages to be accessed programatically. Basically,
  that page may be accessed as a 'web service'. So the same page may
 be
  arrived at in 2 ways - the result of a form submission from
 another
  page in the same app, or the result of a direct http connection.
 When
  accessed as a web service, there are a few extra requirements -
 the
  page must be POSTed to, and there must be an extra http request
 header
  for authorization.
 
  I was thinking that the page could make sure that it always is
 POSTed
  to, but when arrived at in the context of a form submission in the
  application, it apparently ends up being the result of a redirect
  after the form post, so the page does not think it was posted to.
 So I
  think perhaps the page should only ensure it was posted to if it's
  from outside the application. Is there a way for the page to know
 that
  its referrer is another page in the same application? Check the
  referrer header?
 
  Is trying to overload this page like this crazy? I thought it
 would be
  less work and a cleaner design, but am not sure when I should just
  give up.
 
  Lowell
 
 

  
 -
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and take
  control of your XML. No limits. Just data. Click to get it now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 



  
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

  
 https://lists.sourceforge.net/lists/listinfo/wicket-user


   
   
  
 -
This SF.net email is sponsored by 

Re: [Wicket-user] Wicket and web services

2007-05-14 Thread Igor Vaynberg

the way it works now, with a redirect after post, is that if you press
refresh there will be no repost. if they press the back button then they can
submit the form again.

without redirect the only difference is that refreshing the page that shows
after the form has been submitted will ask the user to resubmit - which is
bad. it is much better if they are forwarded to a view page that they can
refresh safely. which is what the redirect after post pattern does.

-igor


On 5/14/07, Lowell Kirsh [EMAIL PROTECTED] wrote:


But I want the browser to ask that, because a re-post is dangerous.
Perhpas the dangerous logic should be in the submission page instead
of the results page.

On 5/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
 you should do a redirect.

 Because if i do a refresh of the browser with the form url in it
 i think think the browser ask me do you want to resubmit it (and i guess
 that is a post again??)

 johan


  On 5/14/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
  Hi, I'm not sure I understand what you just said. I think I do have
  the url of the post in my browser. That is, now that I have set
  redirect=false, when you reload the results page, it will execute the
  logic (with side effects) again. But I'm thinking perhaps I'm doing
  this wrong.
 
  Basically, I have a form and a results page. The way I have it now is
  that during the rendering of the results page, the side-effect-having
  logic gets executed. But I just realized another way of doing this
  would be to have that logic execute in the form page, and then pass
  the results of that to the results page. In general, when you have a
  form and a results page, do you want to put the side effect logic (eg.
  a database insert) in the form page or in the results page?
 
  On 5/13/07, Johan Compagner [EMAIL PROTECTED] wrote:
   but you don't submit again because in the browser you never
   have the url of the post (at least in the default settings of
wicket)
   because then we always do a redirect after post
  
   johan
  
  
  
On 5/12/07, Lowell Kirsh  [EMAIL PROTECTED] wrote:
 why would you test for post in the resulting page?
   
The page has side effects, so if you are viewing it in your
browser
and press refresh, it should not execute again. Or at least, there
should be a warning before submitting.
   
I think my best bet is to not try to overload the functionality of
this page. I will probably create another page for programmatic
access.
   
 A form will be submitted to a page. (that will be done in a page
and
   then
 method should be post)
 then a redirect will happen to a page that you set as a result
page
 (or
   it
 is the same)
 and that page will not be in a post but will be in a get

 but how do you set the result page?
 you can try setRedirect(false) after you set the result page.

 How is your webservice access your page? that does the post to
the
 form?
 But then you are in the submit and you know you are ok.

 johan



 On 5/11/07, Lowell Kirsh [EMAIL PROTECTED]  wrote:
 
  I want some of my pages to be accessed programatically.
Basically,
  that page may be accessed as a 'web service'. So the same page
may
 be
  arrived at in 2 ways - the result of a form submission from
 another
  page in the same app, or the result of a direct http
connection.
 When
  accessed as a web service, there are a few extra requirements
-
 the
  page must be POSTed to, and there must be an extra http
request
 header
  for authorization.
 
  I was thinking that the page could make sure that it always is
 POSTed
  to, but when arrived at in the context of a form submission in
the
  application, it apparently ends up being the result of a
redirect
  after the form post, so the page does not think it was posted
to.
 So I
  think perhaps the page should only ensure it was posted to if
it's
  from outside the application. Is there a way for the page to
know
 that
  its referrer is another page in the same application? Check
the
  referrer header?
 
  Is trying to overload this page like this crazy? I thought it
 would be
  less work and a cleaner design, but am not sure when I should
just
  give up.
 
  Lowell
 
 

  

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
take
  control of your XML. No limits. Just data. Click to get it
now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 



  

-
 This SF.net email is 

Re: [Wicket-user] Wicket and web services

2007-05-13 Thread Johan Compagner

but you don't submit again because in the browser you never
have the url of the post (at least in the default settings of wicket)
because then we always do a redirect after post

johan


On 5/12/07, Lowell Kirsh [EMAIL PROTECTED] wrote:


 why would you test for post in the resulting page?

The page has side effects, so if you are viewing it in your browser
and press refresh, it should not execute again. Or at least, there
should be a warning before submitting.

I think my best bet is to not try to overload the functionality of
this page. I will probably create another page for programmatic
access.

 A form will be submitted to a page. (that will be done in a page and
then
 method should be post)
 then a redirect will happen to a page that you set as a result page (or
it
 is the same)
 and that page will not be in a post but will be in a get

 but how do you set the result page?
 you can try setRedirect(false) after you set the result page.

 How is your webservice access your page? that does the post to the form?
 But then you are in the submit and you know you are ok.

 johan



 On 5/11/07, Lowell Kirsh [EMAIL PROTECTED]  wrote:
 
  I want some of my pages to be accessed programatically. Basically,
  that page may be accessed as a 'web service'. So the same page may be
  arrived at in 2 ways - the result of a form submission from another
  page in the same app, or the result of a direct http connection. When
  accessed as a web service, there are a few extra requirements - the
  page must be POSTed to, and there must be an extra http request header
  for authorization.
 
  I was thinking that the page could make sure that it always is POSTed
  to, but when arrived at in the context of a form submission in the
  application, it apparently ends up being the result of a redirect
  after the form post, so the page does not think it was posted to. So I
  think perhaps the page should only ensure it was posted to if it's
  from outside the application. Is there a way for the page to know that
  its referrer is another page in the same application? Check the
  referrer header?
 
  Is trying to overload this page like this crazy? I thought it would be
  less work and a cleaner design, but am not sure when I should just
  give up.
 
  Lowell
 
 

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and take
  control of your XML. No limits. Just data. Click to get it now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 



-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Re: [Wicket-user] Wicket and web services

2007-05-13 Thread Lowell Kirsh
Hi, I'm not sure I understand what you just said. I think I do have
the url of the post in my browser. That is, now that I have set
redirect=false, when you reload the results page, it will execute the
logic (with side effects) again. But I'm thinking perhaps I'm doing
this wrong.

Basically, I have a form and a results page. The way I have it now is
that during the rendering of the results page, the side-effect-having
logic gets executed. But I just realized another way of doing this
would be to have that logic execute in the form page, and then pass
the results of that to the results page. In general, when you have a
form and a results page, do you want to put the side effect logic (eg.
a database insert) in the form page or in the results page?

On 5/13/07, Johan Compagner [EMAIL PROTECTED] wrote:
 but you don't submit again because in the browser you never
 have the url of the post (at least in the default settings of wicket)
 because then we always do a redirect after post

 johan



  On 5/12/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
   why would you test for post in the resulting page?
 
  The page has side effects, so if you are viewing it in your browser
  and press refresh, it should not execute again. Or at least, there
  should be a warning before submitting.
 
  I think my best bet is to not try to overload the functionality of
  this page. I will probably create another page for programmatic
  access.
 
   A form will be submitted to a page. (that will be done in a page and
 then
   method should be post)
   then a redirect will happen to a page that you set as a result page (or
 it
   is the same)
   and that page will not be in a post but will be in a get
  
   but how do you set the result page?
   you can try setRedirect(false) after you set the result page.
  
   How is your webservice access your page? that does the post to the form?
   But then you are in the submit and you know you are ok.
  
   johan
  
  
  
   On 5/11/07, Lowell Kirsh [EMAIL PROTECTED]  wrote:
   
I want some of my pages to be accessed programatically. Basically,
that page may be accessed as a 'web service'. So the same page may be
arrived at in 2 ways - the result of a form submission from another
page in the same app, or the result of a direct http connection. When
accessed as a web service, there are a few extra requirements - the
page must be POSTed to, and there must be an extra http request header
for authorization.
   
I was thinking that the page could make sure that it always is POSTed
to, but when arrived at in the context of a form submission in the
application, it apparently ends up being the result of a redirect
after the form post, so the page does not think it was posted to. So I
think perhaps the page should only ensure it was posted to if it's
from outside the application. Is there a way for the page to know that
its referrer is another page in the same application? Check the
referrer header?
   
Is trying to overload this page like this crazy? I thought it would be
less work and a cleaner design, but am not sure when I should just
give up.
   
Lowell
   
   
  
 -
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
  
 -
   This SF.net email is sponsored by DB2 Express
   Download DB2 Express C - the FREE version of DB2 express and take
   control of your XML. No limits. Just data. Click to get it now.
   http://sourceforge.net/powerbar/db2/
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
 
 
 -
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and take
  control of your XML. No limits. Just data. Click to get it now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 

[Wicket-user] Wicket and web services

2007-05-11 Thread Lowell Kirsh
I want some of my pages to be accessed programatically. Basically,
that page may be accessed as a 'web service'. So the same page may be
arrived at in 2 ways - the result of a form submission from another
page in the same app, or the result of a direct http connection. When
accessed as a web service, there are a few extra requirements - the
page must be POSTed to, and there must be an extra http request header
for authorization.

I was thinking that the page could make sure that it always is POSTed
to, but when arrived at in the context of a form submission in the
application, it apparently ends up being the result of a redirect
after the form post, so the page does not think it was posted to. So I
think perhaps the page should only ensure it was posted to if it's
from outside the application. Is there a way for the page to know that
its referrer is another page in the same application? Check the
referrer header?

Is trying to overload this page like this crazy? I thought it would be
less work and a cleaner design, but am not sure when I should just
give up.

Lowell

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user