Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Hi, Nikolaos
I don't think the choice of JS framework could affect validation in any
way. After all you do use ajax, don't you? :)
Here's how we solved it in one of our projects:
1. On client side we add an event listener to each form field (we listen
for onChange event).
2. This event listener does a plain vanilla ajax request. Something like:
/my/action/bean?fieldName=User+ValueajaxValidate=atrue
In our action bean we have fields with some validation rules and
(optionally) custom methods assigned. If we leave it as is it won't handle
our request correctly because some other fields might be required. That's
why ..
3. Our action bean implements ValidationErrorHandler [1] interface to
hijack the default validation handling mechanism.
4. By the time handleValidationErrors method is called all validation
rules are already applied and ValidationErrors array is already filled in.
5. Inside this handleValidationErrors we check for ajaxValidate parameter
in request and if it's present we filter out validation errors
corresponding to filedName field.
6. If no errors are found we return a JSON {status: 'ok'}. Otherwise we
return JSON with validation errors.
7. On a client side aour Ajax callback function expects a JSON response
data. If JSON has any errors we show them to user.
It's not really hard to implement ajax validation this way and it's
completely library-agnostic. In our project we use jQuery so I don't show
the code to you to avoid confusion. But if you follow the guidelines
that's going to be easy.
Note that we still required to have a ajaxValidate handler defined in our
action bean. It's going to be invoked when the last field in a form is
being validated and is going to pass validation. This is because in this
case ValidationErrors array is empty and handleValidationErrors isn't
called. If this method isn't defined Stripes will use a default handler -
and it might be not something you intend to.
Cheers,
Andrey
[1]
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/validation/ValidationErrorHandler.html
On Mon, 15 Nov 2010 20:05:09 +0200, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Andrey,
Clearly the choice of JS framework is not the issue here. However, what
I was looking for was a MooTools version of the jQuery script that Aaron
Porter wrote that leverages the field-metadata tag and that is why I
mentioned MooTools here.
Your suggestion however is very interesting and sounds very simple to
implement and does solve the localization of error messages.
However, I am concerned thought that doing an Ajax call per each field
change will amount to a lot of extra server requests and may be a
performance clog on a high traffic site. Did you ever consider limiting
to 1 Ajax request on hitting form submit... basically a pre-validation
to actual form submission?
Thoughts???
--Nikolaos
Andrey Listochkin wrote:
Hi, Nikolaos
I don't think the choice of JS framework could affect validation in
any way. After all you do use ajax, don't you? :)
Here's how we solved it in one of our projects:
1. On client side we add an event listener to each form field (we
listen for onChange event).
2. This event listener does a plain vanilla ajax request. Something like:
/my/action/bean?fieldName=User+ValueajaxValidate=atrue
In our action bean we have fields with some validation rules and
(optionally) custom methods assigned. If we leave it as is it won't
handle our request correctly because some other fields might be
required. That's why ..
3. Our action bean implements ValidationErrorHandler [1] interface to
hijack the default validation handling mechanism.
4. By the time handleValidationErrors method is called all validation
rules are already applied and ValidationErrors array is already filled
in.
5. Inside this handleValidationErrors we check for ajaxValidate
parameter in request and if it's present we filter out validation
errors corresponding to filedName field.
6. If no errors are found we return a JSON {status: 'ok'}. Otherwise
we return JSON with validation errors.
7. On a client side aour Ajax callback function expects a JSON
response data. If JSON has any errors we show them to user.
It's not really hard to implement ajax validation this way and it's
completely library-agnostic. In our project we use jQuery so I don't
show the code to you to avoid confusion. But if you follow the
guidelines that's going to be easy.
Note that we still required to have a ajaxValidate handler defined in
our action bean. It's going to be invoked when the last field in a
form is being validated and is going to pass validation. This is
because in this case ValidationErrors array is empty and
handleValidationErrors isn't called. If this method isn't defined
Stripes will use a default handler - and it might be not something you
intend to.
Cheers,
Andrey
[1]
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/validation/ValidationErrorHandler.html
On Mon, 15 Nov 2010 20:05:09 +0200, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
[Stripes-users] Preventing multiple form submission
Hi, Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? --Nikolaos -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Preventing multiple form submission
On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote: Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? It is always possible to render a hidden field nonce with a bit of opaque information (like a random long, hex-encoded), that is also stored in the session. Generally, you get a flow like this: - A form is prepared - Generate a few random bytes (e.g. a long, anf hex-encode it) - Store the value in the session - Display the form, including a hidden field nonce with the generated value ... - When receiving a request that's not intended for a default handler, check the field nonce: - If it isn't present, give an error - If it is present but doesn't match the value in the session, present an error message this form has already been submitted, and re-display the form or the detail page - Otherwise the nonce is present and matches the stored value: perfect - Unless there is an error (see above), proceed as usual As a variation you may generate a nonce per form or form/record combination to explicitly allow people to edit multiple things at once. Also, given that I match on default handler or not, it is perfectly possible to handle this using an interceptor and custom form tag. The first check upon submit forced the use of the custom tag, so there will be no omissions there. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Inequality is the inevitable consequence of liberty. =/ () -- Salvador De Madariaga - Anarchy or Hierarchy (1937) signature.asc Description: Digital signature -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
You can return a JSP file in response to your AJAX request (return new
ForwardResolution(/ajax-response.jsp)).
Making it super easy to include your errors and messages (s:errors/ and
s:messages/).
Not the best traffic saver though. But at least it allows you to update
small portions of your site.
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Tue, Nov 16, 2010 at 3:03 PM, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Andrey,
Clearly the choice of JS framework is not the issue here. However, what
I was looking for was a MooTools version of the jQuery script that Aaron
Porter wrote that leverages the field-metadata tag and that is why I
mentioned MooTools here.
Your suggestion however is very interesting and sounds very simple to
implement and does solve the localization of error messages.
However, I am concerned thought that doing an Ajax call per each field
change will amount to a lot of extra server requests and may be a
performance clog on a high traffic site. Did you ever consider limiting
to 1 Ajax request on hitting form submit... basically a pre-validation
to actual form submission?
Thoughts???
--Nikolaos
Andrey Listochkin wrote:
Hi, Nikolaos
I don't think the choice of JS framework could affect validation in
any way. After all you do use ajax, don't you? :)
Here's how we solved it in one of our projects:
1. On client side we add an event listener to each form field (we
listen for onChange event).
2. This event listener does a plain vanilla ajax request. Something like:
/my/action/bean?fieldName=User+ValueajaxValidate=atrue
In our action bean we have fields with some validation rules and
(optionally) custom methods assigned. If we leave it as is it won't
handle our request correctly because some other fields might be
required. That's why ..
3. Our action bean implements ValidationErrorHandler [1] interface to
hijack the default validation handling mechanism.
4. By the time handleValidationErrors method is called all validation
rules are already applied and ValidationErrors array is already filled
in.
5. Inside this handleValidationErrors we check for ajaxValidate
parameter in request and if it's present we filter out validation
errors corresponding to filedName field.
6. If no errors are found we return a JSON {status: 'ok'}. Otherwise
we return JSON with validation errors.
7. On a client side aour Ajax callback function expects a JSON
response data. If JSON has any errors we show them to user.
It's not really hard to implement ajax validation this way and it's
completely library-agnostic. In our project we use jQuery so I don't
show the code to you to avoid confusion. But if you follow the
guidelines that's going to be easy.
Note that we still required to have a ajaxValidate handler defined in
our action bean. It's going to be invoked when the last field in a
form is being validated and is going to pass validation. This is
because in this case ValidationErrors array is empty and
handleValidationErrors isn't called. If this method isn't defined
Stripes will use a default handler - and it might be not something you
intend to.
Cheers,
Andrey
[1]
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/validation/ValidationErrorHandler.html
On Mon, 15 Nov 2010 20:05:09 +0200, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}taghttp://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe%7B%7Bfieldmetadata%7D%7Dtag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying
Re: [Stripes-users] Preventing multiple form submission
I usually do that on the client side:
document.getElementById(submitButton).onclick = function(e) {
e.preventDefault();
this.disabled = true;
this.form.submit();
};
But if the user presses the stop button before the response is returned, he
will have to refresh the page in order to re-enable the submit button.
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Tue, Nov 16, 2010 at 3:34 PM, Oscar Westra van Holthe - Kind
os...@westravanholthe.nl wrote:
On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote:
Just wondering how others elegantly solve this situation:
1) User is editing a form and fills it out and clicks submit button
2) Form gets successfully processed on the server however before a
response is returned the user hits the stop button, their internet
connection drops, etc...
4) User clicks on submit again and tries to re-submit the same
information(*)
Now, this would be trivial if there was a unique piece of information in
the content being posted however lets assume someone posting some blog /
news content wherein there is really no unique info (e.g. although it
may be rare there is nothing wrong with 2 people say posting the same
content with the same title).
I was thinking to tag the users session with the last successfully
submitted Stripes _sourcePage field and direct the user to the view
handler if they are trying to do an edit and the _sourcePagematches.
Thoughts???
It is always possible to render a hidden field nonce with a bit of opaque
information (like a random long, hex-encoded), that is also stored in the
session. Generally, you get a flow like this:
- A form is prepared
- Generate a few random bytes (e.g. a long, anf hex-encode it)
- Store the value in the session
- Display the form, including a hidden field nonce with the generated
value
...
- When receiving a request that's not intended for a default handler, check
the field nonce:
- If it isn't present, give an error
- If it is present but doesn't match the value in the session, present an
error message this form has already been submitted, and re-display the
form or the detail page
- Otherwise the nonce is present and matches the stored value: perfect
- Unless there is an error (see above), proceed as usual
As a variation you may generate a nonce per form or form/record combination
to explicitly allow people to edit multiple things at once.
Also, given that I match on default handler or not, it is perfectly
possible to handle this using an interceptor and custom form tag. The first
check upon submit forced the use of the custom tag, so there will be no
omissions there.
Oscar
--
,-_ Oscar Westra van Holthe - Kind
http://www.xs4all.nl/~kindop/http://www.xs4all.nl/%7Ekindop/
/() )
(__ ( Inequality is the inevitable consequence of liberty.
=/ () -- Salvador De Madariaga - Anarchy or Hierarchy (1937)
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAkzipKAACgkQLDKOJAl7tOJnngCg/nFW5qfrRcKTMo7C/uOQ2iqn
XXEAoJRR0AXjseiwUCR7IhZoPYDyd8sx
=jgb0
-END PGP SIGNATURE-
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Preventing multiple form submission
I'm wondering why the stripes form tag and stripes filter don't provide this automatically. It seems like everyone rolls their own version of this, and if they haven't yet they will eventually, since without such a check the application is easy to break. I think this would be a good feature for stripes-stuff or stripes core even. I believe a lot of other web frameworks offer this right out of the box, and tout it as a useful and necessary feature, which it is. Am I wrong? I know the trend is to say NO to features and bloat, I agree with that generally, but this topic comes up a lot. It could be a big deal to force everyone to implement a new interface or something for handling the failure case, maybe a generic validation error could be used, idk. -Original Message- From: Oscar Westra van Holthe - Kind [mailto:os...@westravanholthe.nl] Sent: Tuesday, November 16, 2010 10:35 AM To: nikol...@brightminds.org; Stripes Users List Subject: Re: [Stripes-users] Preventing multiple form submission On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote: Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? It is always possible to render a hidden field nonce with a bit of opaque information (like a random long, hex-encoded), that is also stored in the session. Generally, you get a flow like this: - A form is prepared - Generate a few random bytes (e.g. a long, anf hex-encode it) - Store the value in the session - Display the form, including a hidden field nonce with the generated value ... - When receiving a request that's not intended for a default handler, check the field nonce: - If it isn't present, give an error - If it is present but doesn't match the value in the session, present an error message this form has already been submitted, and re-display the form or the detail page - Otherwise the nonce is present and matches the stored value: perfect - Unless there is an error (see above), proceed as usual As a variation you may generate a nonce per form or form/record combination to explicitly allow people to edit multiple things at once. Also, given that I match on default handler or not, it is perfectly possible to handle this using an interceptor and custom form tag. The first check upon submit forced the use of the custom tag, so there will be no omissions there. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Inequality is the inevitable consequence of liberty. =/ () -- Salvador De Madariaga - Anarchy or Hierarchy (1937) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Preventing multiple form submission
Struts 1.x provides this functionality... @see org.apache.struts.action.Action#saveToken(HttpServletRequest request), @see org.apache.struts.action.Action#resetToken(HttpServletRequest request), @see org.apache.struts.action.Action#isTokenValid(HttpServletRequest request) It's described in /Struts in Action/ as a synchronizing token and automatically provided in the html:form ... and html:link ... tags. If the action is using tokens, an appropriate hidden field is generated. Regards, Tim PS... I'm only just saying. Not suggesting that Stripes want to do this in core. :) -Original Message- From: Newman, John W [mailto:john.new...@viaoncology.com] Sent: Tuesday, November 16, 2010 1:35 PM To: Stripes Users List; nikol...@brightminds.org Subject: Re: [Stripes-users] Preventing multiple form submission I'm wondering why the stripes form tag and stripes filter don't provide this automatically. It seems like everyone rolls their own version of this, and if they haven't yet they will eventually, since without such a check the application is easy to break. I think this would be a good feature for stripes-stuff or stripes core even. I believe a lot of other web frameworks offer this right out of the box, and tout it as a useful and necessary feature, which it is. Am I wrong? I know the trend is to say NO to features and bloat, I agree with that generally, but this topic comes up a lot. It could be a big deal to force everyone to implement a new interface or something for handling the failure case, maybe a generic validation error could be used, idk. -Original Message- From: Oscar Westra van Holthe - Kind [mailto:os...@westravanholthe.nl] Sent: Tuesday, November 16, 2010 10:35 AM To: nikol...@brightminds.org; Stripes Users List Subject: Re: [Stripes-users] Preventing multiple form submission On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote: Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? It is always possible to render a hidden field nonce with a bit of opaque information (like a random long, hex-encoded), that is also stored in the session. Generally, you get a flow like this: - A form is prepared - Generate a few random bytes (e.g. a long, anf hex-encode it) - Store the value in the session - Display the form, including a hidden field nonce with the generated value ... - When receiving a request that's not intended for a default handler, check the field nonce: - If it isn't present, give an error - If it is present but doesn't match the value in the session, present an error message this form has already been submitted, and re-display the form or the detail page - Otherwise the nonce is present and matches the stored value: perfect - Unless there is an error (see above), proceed as usual As a variation you may generate a nonce per form or form/record combination to explicitly allow people to edit multiple things at once. Also, given that I match on default handler or not, it is perfectly possible to handle this using an interceptor and custom form tag. The first check upon submit forced the use of the custom tag, so there will be no omissions there. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Inequality is the inevitable consequence of liberty. =/ () -- Salvador De Madariaga - Anarchy or Hierarchy (1937) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users Barclays www.barclaycardus.com This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity
Re: [Stripes-users] Preventing multiple form submission
Cool, struts is one but there's a lot of others that provide it. I wasn't necessarily saying stripes needs this to do this now, just trying to get the idea out there for some discussion. If it would end up being a bunch of bloat and extra burden on the developer, forget it; but if we can provide appropriate configuration and offload this thing that every app should have anyway, then why not. Is the token universally good for any http based application or am I missing something? Any reason you would NOT want this feature in your app? Obviously it could be flagged disabled, possibly even by default. -Original Message- From: Stone, Timothy [mailto:tst...@barclaycardus.com] Sent: Tuesday, November 16, 2010 2:11 PM To: Stripes Users List Subject: Re: [Stripes-users] Preventing multiple form submission Struts 1.x provides this functionality... @see org.apache.struts.action.Action#saveToken(HttpServletRequest request), @see org.apache.struts.action.Action#resetToken(HttpServletRequest request), @see org.apache.struts.action.Action#isTokenValid(HttpServletRequest request) It's described in /Struts in Action/ as a synchronizing token and automatically provided in the html:form ... and html:link ... tags. If the action is using tokens, an appropriate hidden field is generated. Regards, Tim PS... I'm only just saying. Not suggesting that Stripes want to do this in core. :) -Original Message- From: Newman, John W [mailto:john.new...@viaoncology.com] Sent: Tuesday, November 16, 2010 1:35 PM To: Stripes Users List; nikol...@brightminds.org Subject: Re: [Stripes-users] Preventing multiple form submission I'm wondering why the stripes form tag and stripes filter don't provide this automatically. It seems like everyone rolls their own version of this, and if they haven't yet they will eventually, since without such a check the application is easy to break. I think this would be a good feature for stripes-stuff or stripes core even. I believe a lot of other web frameworks offer this right out of the box, and tout it as a useful and necessary feature, which it is. Am I wrong? I know the trend is to say NO to features and bloat, I agree with that generally, but this topic comes up a lot. It could be a big deal to force everyone to implement a new interface or something for handling the failure case, maybe a generic validation error could be used, idk. -Original Message- From: Oscar Westra van Holthe - Kind [mailto:os...@westravanholthe.nl] Sent: Tuesday, November 16, 2010 10:35 AM To: nikol...@brightminds.org; Stripes Users List Subject: Re: [Stripes-users] Preventing multiple form submission On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote: Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? It is always possible to render a hidden field nonce with a bit of opaque information (like a random long, hex-encoded), that is also stored in the session. Generally, you get a flow like this: - A form is prepared - Generate a few random bytes (e.g. a long, anf hex-encode it) - Store the value in the session - Display the form, including a hidden field nonce with the generated value ... - When receiving a request that's not intended for a default handler, check the field nonce: - If it isn't present, give an error - If it is present but doesn't match the value in the session, present an error message this form has already been submitted, and re-display the form or the detail page - Otherwise the nonce is present and matches the stored value: perfect - Unless there is an error (see above), proceed as usual As a variation you may generate a nonce per form or form/record combination to explicitly allow people to edit multiple things at once. Also, given that I match on default handler or not, it is perfectly possible to handle this using an interceptor and custom form tag. The first check upon submit forced the use of the custom tag, so there will be no omissions there. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Inequality is the
Re: [Stripes-users] Preventing multiple form submission
On 16-11-2010 at 19:43, Newman, John W wrote: Is the token universally good for any http based application or am I missing something? Any reason you would NOT want this feature in your app? Obviously it could be flagged disabled, possibly even by default. In general, I don't think it would take much, except that it adds at least one error you'll need to handle (form already submitted). This needs to be thought out well. Then, another tricky part is whether the token is per application, page (form), or per form/record combination. But I guess that's easily enough made pluggable. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( No trees were killed in the creation of this message. However, =/ () many electrons were terribly inconvenienced. signature.asc Description: Digital signature -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Preventing multiple form submission
Hi Nikolaos, have you used the transaction token mechanism in Struts? A similar mechanism should solve your problem. It would be really easy to implement. If you don't know what I am talking about, let me know and I will explain further. Cheers, Angel. Nikolaos Giannopoulos wrote: Hi, Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? --Nikolaos -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- View this message in context: http://old.nabble.com/Preventing-multiple-form-submission-tp30229773p30233802.html Sent from the stripes-users mailing list archive at Nabble.com. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] 1.5.4 upgrade and layout-component problem
I'm pretty sure this is happening because in previous releases when you
evaluate ${someLayoutComponent} you get a real String object, while in the
current release you get a LayoutComponentRenderer. EL knows how to coerce a
String to a Long, but it does not know how to do that with a
LayoutComponentRenderer. I did not anticipate people using layout components
in the way you seem to be using this one. If you don't mind, I'd like to see
a few JSP snippets to give me a better idea of exactly what you're doing. It
will help me figure out how to approach a solution, if a solution is
possible.
-Ben
On Sun, Nov 14, 2010 at 3:59 AM, Andrew Court andy.co...@gmail.com wrote:
Hi all,
I just upgraded to 1.5.4 and am getting the following error:
javax.el.ELException: Cannot convert 1 of type class
net.sourceforge.stripes.tag.layout.LayoutComponentRenderer to class
java.lang.Long
I am setting an integer named menuIndex in a layout-component tag in each
jsp page (as below) to set a corresponding menu index property in the
shared
layout template
stripes:layout-component name=menuIndex1/stripes:layout-component
This worked fine in 1.5.3. It seems like I can set menuIndex as an
attribute
of the containing layout-render tag to make it work in 1.5.4, but would
rather not change my existing jsps if need be. Can anyone shed any light on
this please?
Thanks,
Andrew
--
View this message in context:
http://old.nabble.com/1.5.4-upgrade-and-layout-component-problem-tp30211356p30211356.html
Sent from the stripes-users mailing list archive at Nabble.com.
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
