Re: Floating the idea of an @DontInjectParameters annotation

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

paul.barry
I just ran into this cancel problem myself.  Specifically, say you
have a date field on the form.  You bring up the form in edit mode.
The user changes the date to something that is invalid.  So the just
press cancel, but if that cancel goes to the same ActionBean, then the
DateConvert tries to bind the still screwed up date field and
generates an error.  So I also would vore for a @DontBind annotation.
Is this in JIRA yet?

I don't like @Cancel, it's too application specific.  @DontBind makes
sense, you don't want  the form to bind.  Also, @Cancel just seems out
of place, whereas @DontBind is similar to the already existing
@DontValidate.

On 7/7/06, Tim Fennell <[hidden email]> wrote:

> Hmm,
>
> If there's significant demand for it, it probably wouldn't be too
> hard to implement a @DontBind annotation or something similar.  I
> might want to take a step back and figure out are there certain
> patterns (like this one) that would make it more sensible to just
> have a @Cancel annotation that turns off both validation and
> binding...or if it'd be better to control the two independently.
>
> A (slight) improvement over your current version would be to call
> getContext().getEventName() which will tell you what event Stripes is
> going to execute.  It's a bit cleaner than digging through the
> request yourself.
>
> -t
>
>
> On Jul 7, 2006, at 10:43 AM, RepublicanJew wrote:
>
> > I'm sanding the rough edges of my Stripes/Hibernate PoC, and I
> > found a situation
> > that seemed suboptimal.  For the few forms that comprise the PoC, I
> > have a
> > Cancel button on the forms that is implemented as an s:submit
> > pointed at the
> > cancel() event handler of the same ActionBean that houses the view
> > () and save()
> > event handlers.  In the setContext() method of my ActionBean, I
> > have code that
> > looks up the object graph being edited on the page so that it can
> > already be in
> > place when Stripes injects the converted form parameters into the
> > graph.
> > Unfortunately, if someone wants to cancel out of the form and they
> > have made
> > changes on the form, then, without intervening code, those changes
> > will be
> > injected into my model.  Which in Hibernate will result in those
> > changes being
> > saved once the transaction is comitted--even if you don't call
> > session.saveOrUpdate().  I ended up adding said intervening code
> > such that it
> > looks for a "cancel" request parameter and, if found, won't lookup
> > my entity
> > graph.  When I hit cancel now, it generates several INFO log
> > entries about not
> > being able to inject form parms into a null object.  Which I can
> > frankly live
> > with if that's where things end.
> >
> > But I couldn't help but think that this seems fairly analogous to
> > the reasoning
> > behind the @DontValidate annotation.  Would anyone else besides me
> > find it
> > useful to have an @DontInjectParameters annotation so that I don't
> > have an
> > unnecessary coupling between my cancel() event handler and code
> > that references
> > the "cancel" req parm in my setContect() method?  This is from a
> > guy who frankly
> > has no idea how difficult it is to implement support for new
> > annotations, so I
> > understand if this is ridiculously simplistic thinking.  Is this
> > the sort of
> > thing where people in my situation should just dive into the code
> > and try to
> > implement it myself?
> >
> > -RJ
> >
> >
> > Using Tomcat but need to do more? Need to support web services,
> > security?
> > Get stuff done quickly with pre-integrated technology to make your
> > job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Jasper Fontaine
Since i've encountered this problem also I agree with this idea.
While it only seems to happen with a cancel button for now, in the
abstract sense i think it's cleaner to have the @DontBind annotation.

Secondly, when checking the different LifecycleStages i was thinking
about the use of a @DontCustomValidate tag but decided against it: that
might be a bit overkill - why would you ever want to validate but not
execute the custom validation?

Paul Barry wrote:

> I just ran into this cancel problem myself.  Specifically, say you
> have a date field on the form.  You bring up the form in edit mode.
> The user changes the date to something that is invalid.  So the just
> press cancel, but if that cancel goes to the same ActionBean, then the
> DateConvert tries to bind the still screwed up date field and
> generates an error.  So I also would vore for a @DontBind annotation.
> Is this in JIRA yet?
>
> I don't like @Cancel, it's too application specific.  @DontBind makes
> sense, you don't want  the form to bind.  Also, @Cancel just seems out
> of place, whereas @DontBind is similar to the already existing
> @DontValidate.
>
> On 7/7/06, Tim Fennell <[hidden email]> wrote:
>> Hmm,
>>
>> If there's significant demand for it, it probably wouldn't be too
>> hard to implement a @DontBind annotation or something similar.  I
>> might want to take a step back and figure out are there certain
>> patterns (like this one) that would make it more sensible to just
>> have a @Cancel annotation that turns off both validation and
>> binding...or if it'd be better to control the two independently.
>>
>> A (slight) improvement over your current version would be to call
>> getContext().getEventName() which will tell you what event Stripes is
>> going to execute.  It's a bit cleaner than digging through the
>> request yourself.
>>
>> -t
>>
>>
>> On Jul 7, 2006, at 10:43 AM, RepublicanJew wrote:
>>
>>> I'm sanding the rough edges of my Stripes/Hibernate PoC, and I
>>> found a situation
>>> that seemed suboptimal.  For the few forms that comprise the PoC, I
>>> have a
>>> Cancel button on the forms that is implemented as an s:submit
>>> pointed at the
>>> cancel() event handler of the same ActionBean that houses the view
>>> () and save()
>>> event handlers.  In the setContext() method of my ActionBean, I
>>> have code that
>>> looks up the object graph being edited on the page so that it can
>>> already be in
>>> place when Stripes injects the converted form parameters into the
>>> graph.
>>> Unfortunately, if someone wants to cancel out of the form and they
>>> have made
>>> changes on the form, then, without intervening code, those changes
>>> will be
>>> injected into my model.  Which in Hibernate will result in those
>>> changes being
>>> saved once the transaction is comitted--even if you don't call
>>> session.saveOrUpdate().  I ended up adding said intervening code
>>> such that it
>>> looks for a "cancel" request parameter and, if found, won't lookup
>>> my entity
>>> graph.  When I hit cancel now, it generates several INFO log
>>> entries about not
>>> being able to inject form parms into a null object.  Which I can
>>> frankly live
>>> with if that's where things end.
>>>
>>> But I couldn't help but think that this seems fairly analogous to
>>> the reasoning
>>> behind the @DontValidate annotation.  Would anyone else besides me
>>> find it
>>> useful to have an @DontInjectParameters annotation so that I don't
>>> have an
>>> unnecessary coupling between my cancel() event handler and code
>>> that references
>>> the "cancel" req parm in my setContect() method?  This is from a
>>> guy who frankly
>>> has no idea how difficult it is to implement support for new
>>> annotations, so I
>>> understand if this is ridiculously simplistic thinking.  Is this
>>> the sort of
>>> thing where people in my situation should just dive into the code
>>> and try to
>>> implement it myself?
>>>
>>> -RJ
>>>
>>>
>>> Using Tomcat but need to do more? Need to support web services,
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your
>>> job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?
>>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Stripes-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Stripes-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Andy-90
In reply to this post by paul.barry
Hi all,

I think @DontBind is not very useful. In the cancel event, I
would still like binding done. What I don't want is to be
stopped by validation errors (if there are problems binding
the field, then the field will just be null). Sometimes, my
cancel event handler will need to refer to the values that
were rendered as hidden fields.

Consider a page designed to view a database record. Given an
id, the view event handler will look up the db for the
record, and the jsp will display the record in read-only
mode, with a hidden field for the id. On this page there is
an "edit" button linking back to the same ActionBean.

The edit event handler will again look up the db (making
sure the current user is allowed to edit the record), but it
goes to another jsp which will render the fields in text
boxes, again with a hidden field for the id. On this page
there are "save" and "cancel" buttons. The cancel event
handler will invoke view(), which will use the hidden id.

Let's say one of the fields is a date field. User enters an
invalid date, then clicks cancel. At this point binding
fails and the user remains at the source page (edit jsp).

If we add @DontBind to cancel(), then when it calls view(),
the hidden id will no longer be there.

So I think it is more useful to have something like
@IgnoreValidationErrors to annotate such event handlers.
When there are validation errors, the event handler will
still be executed and may decide the Resolution to return.
If the validation errors are not cleared, then the
validation errors may be shown by the jsp where possible (of
course this is not possible for StreamingResolution or
RedirectResolution without flash).

Thoughts?

Andy


On Mon, 16 Oct 2006, Paul Barry wrote:
> I just ran into this cancel problem myself.  Specifically, say you
> have a date field on the form.  You bring up the form in edit mode.
> The user changes the date to something that is invalid.  So the just
> press cancel, but if that cancel goes to the same ActionBean, then the
> DateConvert tries to bind the still screwed up date field and
> generates an error.  So I also would vore for a @DontBind annotation.
> Is this in JIRA yet?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Ben Gunter
In special cases like this, you can get the value you need directly from the request in your event handler. E.g.:

@DontBind
@DontValidate
@HandlesEvent("cancel")
public Resolution cancel() {
    String id = getContext().getParameter("id");
    return new RedirectResolution("/path/to/page.jsp").addParameter("id", id);
}


This is more efficient than going through the whole type conversion,  binding, and validation process to get at one or two values you might need. Those values would then need to be converted to Strings again anyway to append them as request parameters.

-Ben

Andy wrote:
Hi all,

I think @DontBind is not very useful. In the cancel event, I
would still like binding done. What I don't want is to be
stopped by validation errors (if there are problems binding
the field, then the field will just be null). Sometimes, my
cancel event handler will need to refer to the values that
were rendered as hidden fields.

Consider a page designed to view a database record. Given an
id, the view event handler will look up the db for the
record, and the jsp will display the record in read-only
mode, with a hidden field for the id. On this page there is
an "edit" button linking back to the same ActionBean.

The edit event handler will again look up the db (making
sure the current user is allowed to edit the record), but it
goes to another jsp which will render the fields in text
boxes, again with a hidden field for the id. On this page
there are "save" and "cancel" buttons. The cancel event
handler will invoke view(), which will use the hidden id.

Let's say one of the fields is a date field. User enters an
invalid date, then clicks cancel. At this point binding
fails and the user remains at the source page (edit jsp).

If we add @DontBind to cancel(), then when it calls view(),
the hidden id will no longer be there.

So I think it is more useful to have something like
@IgnoreValidationErrors to annotate such event handlers.
When there are validation errors, the event handler will
still be executed and may decide the Resolution to return.
If the validation errors are not cleared, then the
validation errors may be shown by the jsp where possible (of
course this is not possible for StreamingResolution or
RedirectResolution without flash).

Thoughts?

Andy


On Mon, 16 Oct 2006, Paul Barry wrote:
  
I just ran into this cancel problem myself.  Specifically, say you
have a date field on the form.  You bring up the form in edit mode.
The user changes the date to something that is invalid.  So the just
press cancel, but if that cancel goes to the same ActionBean, then the
DateConvert tries to bind the still screwed up date field and
generates an error.  So I also would vore for a @DontBind annotation.
Is this in JIRA yet?
    

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

paul.barry
In reply to this post by Andy-90
I think what you are suggesting would be correctly called
@IgnoreBindingErrors.  You would want stripes to try and bind, set
things to null where it can't, then I assume you would have
@DontValidate on your cancel handler, so validation wouldn't happen
and then your cancel handler would get called.

I don't see why you couldn't have both.  There are going to be other
cases where people really don't want any binding to happen, and cases
where your don't want a binding error to cause stripes to send the
user back to the source page.

On 10/17/06, Andy <[hidden email]> wrote:

> Hi all,
>
> I think @DontBind is not very useful. In the cancel event, I
> would still like binding done. What I don't want is to be
> stopped by validation errors (if there are problems binding
> the field, then the field will just be null). Sometimes, my
> cancel event handler will need to refer to the values that
> were rendered as hidden fields.
>
> Consider a page designed to view a database record. Given an
> id, the view event handler will look up the db for the
> record, and the jsp will display the record in read-only
> mode, with a hidden field for the id. On this page there is
> an "edit" button linking back to the same ActionBean.
>
> The edit event handler will again look up the db (making
> sure the current user is allowed to edit the record), but it
> goes to another jsp which will render the fields in text
> boxes, again with a hidden field for the id. On this page
> there are "save" and "cancel" buttons. The cancel event
> handler will invoke view(), which will use the hidden id.
>
> Let's say one of the fields is a date field. User enters an
> invalid date, then clicks cancel. At this point binding
> fails and the user remains at the source page (edit jsp).
>
> If we add @DontBind to cancel(), then when it calls view(),
> the hidden id will no longer be there.
>
> So I think it is more useful to have something like
> @IgnoreValidationErrors to annotate such event handlers.
> When there are validation errors, the event handler will
> still be executed and may decide the Resolution to return.
> If the validation errors are not cleared, then the
> validation errors may be shown by the jsp where possible (of
> course this is not possible for StreamingResolution or
> RedirectResolution without flash).
>
> Thoughts?
>
> Andy
>
>
> On Mon, 16 Oct 2006, Paul Barry wrote:
> > I just ran into this cancel problem myself.  Specifically, say you
> > have a date field on the form.  You bring up the form in edit mode.
> > The user changes the date to something that is invalid.  So the just
> > press cancel, but if that cancel goes to the same ActionBean, then the
> > DateConvert tries to bind the still screwed up date field and
> > generates an error.  So I also would vore for a @DontBind annotation.
> > Is this in JIRA yet?
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

paul.barry
In reply to this post by Ben Gunter
Good point.

On 10/17/06, Ben Gunter <[hidden email]> wrote:

>
>  In special cases like this, you can get the value you need directly from
> the request in your event handler. E.g.:
>
>  @DontBind
>  @DontValidate
>  @HandlesEvent("cancel")
>  public Resolution cancel() {
>      String id = getContext().getParameter("id");
>      return new
> RedirectResolution("/path/to/page.jsp").addParameter("id",
> id);
>  }
>
>  This is more efficient than going through the whole type conversion,
> binding, and validation process to get at one or two values you might need.
> Those values would then need to be converted to Strings again anyway to
> append them as request parameters.
>
>  -Ben
>
>
>  Andy wrote:
>  Hi all,
>
> I think @DontBind is not very useful. In the cancel event, I
> would still like binding done. What I don't want is to be
> stopped by validation errors (if there are problems binding
> the field, then the field will just be null). Sometimes, my
> cancel event handler will need to refer to the values that
> were rendered as hidden fields.
>
> Consider a page designed to view a database record. Given an
> id, the view event handler will look up the db for the
> record, and the jsp will display the record in read-only
> mode, with a hidden field for the id. On this page there is
> an "edit" button linking back to the same ActionBean.
>
> The edit event handler will again look up the db (making
> sure the current user is allowed to edit the record), but it
> goes to another jsp which will render the fields in text
> boxes, again with a hidden field for the id. On this page
> there are "save" and "cancel" buttons. The cancel event
> handler will invoke view(), which will use the hidden id.
>
> Let's say one of the fields is a date field. User enters an
> invalid date, then clicks cancel. At this point binding
> fails and the user remains at the source page (edit jsp).
>
> If we add @DontBind to cancel(), then when it calls view(),
> the hidden id will no longer be there.
>
> So I think it is more useful to have something like
> @IgnoreValidationErrors to annotate such event handlers.
> When there are validation errors, the event handler will
> still be executed and may decide the Resolution to return.
> If the validation errors are not cleared, then the
> validation errors may be shown by the jsp where possible (of
> course this is not possible for StreamingResolution or
> RedirectResolution without flash).
>
> Thoughts?
>
> Andy
>
>
> On Mon, 16 Oct 2006, Paul Barry wrote:
>
>
>  I just ran into this cancel problem myself. Specifically, say you
> have a date field on the form. You bring up the form in edit mode.
> The user changes the date to something that is invalid. So the just
> press cancel, but if that cancel goes to the same ActionBean, then the
> DateConvert tries to bind the still screwed up date field and
> generates an error. So I also would vore for a @DontBind annotation.
> Is this in JIRA yet?
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Ben Gunter
Thanks. I actually screwed up one line of that code:

String id = getContext().getRequest().getParameter("id");

-Ben

Paul Barry wrote:
Good point.

On 10/17/06, Ben Gunter [hidden email] wrote:
  
 In special cases like this, you can get the value you need directly from
the request in your event handler. E.g.:

 @DontBind
 @DontValidate
 @HandlesEvent("cancel")
 public Resolution cancel() {
     String id = getContext().getParameter("id");
     return new
RedirectResolution("/path/to/page.jsp").addParameter("id",
id);
 }

 This is more efficient than going through the whole type conversion,
binding, and validation process to get at one or two values you might need.
Those values would then need to be converted to Strings again anyway to
append them as request parameters.

 -Ben


 Andy wrote:
 Hi all,

I think @DontBind is not very useful. In the cancel event, I
would still like binding done. What I don't want is to be
stopped by validation errors (if there are problems binding
the field, then the field will just be null). Sometimes, my
cancel event handler will need to refer to the values that
were rendered as hidden fields.

Consider a page designed to view a database record. Given an
id, the view event handler will look up the db for the
record, and the jsp will display the record in read-only
mode, with a hidden field for the id. On this page there is
an "edit" button linking back to the same ActionBean.

The edit event handler will again look up the db (making
sure the current user is allowed to edit the record), but it
goes to another jsp which will render the fields in text
boxes, again with a hidden field for the id. On this page
there are "save" and "cancel" buttons. The cancel event
handler will invoke view(), which will use the hidden id.

Let's say one of the fields is a date field. User enters an
invalid date, then clicks cancel. At this point binding
fails and the user remains at the source page (edit jsp).

If we add @DontBind to cancel(), then when it calls view(),
the hidden id will no longer be there.

So I think it is more useful to have something like
@IgnoreValidationErrors to annotate such event handlers.
When there are validation errors, the event handler will
still be executed and may decide the Resolution to return.
If the validation errors are not cleared, then the
validation errors may be shown by the jsp where possible (of
course this is not possible for StreamingResolution or
RedirectResolution without flash).

Thoughts?

Andy


On Mon, 16 Oct 2006, Paul Barry wrote:


 I just ran into this cancel problem myself. Specifically, say you
have a date field on the form. You bring up the form in edit mode.
The user changes the date to something that is invalid. So the just
press cancel, but if that cancel goes to the same ActionBean, then the
DateConvert tries to bind the still screwed up date field and
generates an error. So I also would vore for a @DontBind annotation.
Is this in JIRA yet?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



    

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Andy-90
Hi,

On Tue, 17 Oct 2006, Ben Gunter wrote:
> String id = getContext().getRequest().getParameter("id");

Generally I feel uncomfortable having to do getParameter
hacks. The value of id may have come from the request
parameter, but it may also have come from elsewhere (the
previous flashed actionbean instance during redirect, for
example, if using BeanFirstPopulationStrategy).

In my real use case there are many more parameters being
transferred across pages using hidden fields, and they form
complex objects. A user coming into the view page from the
search page, upon hitting "exit" from the view page, will
want to see the same query and the same page of the results
there (I use Hibernate query-by-example); that is even if
the user went through a few view-edit-view-edit-view cycles.

It seems that @DontBind does have its uses, and so does
@IgnoreBindingErrors. In my case, @IgnoreBindingErrors is
the one that I need. It seems counterproductive to @DontBind
and then manually getParameter as above.

Andy

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Tim Fennell-3
Just to add a little more fuel to the fire here.....  If you specify  
@DontValidate (not the suggested @DontBind) are there use cases where  
you'd actually like to have the validation errors work as they do  
now?  Or is is the case that you'd always want to flow into the event  
handler?

Btw, if we want this to be controllable per-event then I think I'd  
rather go for:
        @DontValidate(suppressBindingError=true)
or something like that.

The question then is simply, if they are supressed, do you still want  
access to them?  If so, where should the go?  If it's the usual  
place, that'd be a bigger change to Stripes because it checks  
context.validationErrors in lots of places to determine if errors  
have shown up after validation, custom validation, event handling etc.

-t

On Oct 17, 2006, at 9:19 AM, Andy wrote:

> Hi,
>
> On Tue, 17 Oct 2006, Ben Gunter wrote:
>> String id = getContext().getRequest().getParameter("id");
>
> Generally I feel uncomfortable having to do getParameter
> hacks. The value of id may have come from the request
> parameter, but it may also have come from elsewhere (the
> previous flashed actionbean instance during redirect, for
> example, if using BeanFirstPopulationStrategy).
>
> In my real use case there are many more parameters being
> transferred across pages using hidden fields, and they form
> complex objects. A user coming into the view page from the
> search page, upon hitting "exit" from the view page, will
> want to see the same query and the same page of the results
> there (I use Hibernate query-by-example); that is even if
> the user went through a few view-edit-view-edit-view cycles.
>
> It seems that @DontBind does have its uses, and so does
> @IgnoreBindingErrors. In my case, @IgnoreBindingErrors is
> the one that I need. It seems counterproductive to @DontBind
> and then manually getParameter as above.
>
> Andy
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Floating the idea of an @DontInjectParameters annotation

Nic Holbrook-2
That sounds like a feasible solution to me.  I don't
see where it would be a problem to add an attribute to
an existing annotation.  
As far as the suppressed errors, I would probably just
add a new property called suppressedBindingErrors that
can be accessed by anyone.  The reason for this is you
may have valid binding errors in conjunction with
suppressed binding errors and I think it would get
confusing if they were all mixed together.  The fact
that keeping them in the validationErrors list would
have a rather significant impact on the stripes
framework itself is another good reason to create a
new property.

Nic

--- Tim Fennell <[hidden email]> wrote:

> Just to add a little more fuel to the fire here.....
>  If you specify  
> @DontValidate (not the suggested @DontBind) are
> there use cases where  
> you'd actually like to have the validation errors
> work as they do  
> now?  Or is is the case that you'd always want to
> flow into the event  
> handler?
>
> Btw, if we want this to be controllable per-event
> then I think I'd  
> rather go for:
> @DontValidate(suppressBindingError=true)
> or something like that.
>
> The question then is simply, if they are supressed,
> do you still want  
> access to them?  If so, where should the go?  If
> it's the usual  
> place, that'd be a bigger change to Stripes because
> it checks  
> context.validationErrors in lots of places to
> determine if errors  
> have shown up after validation, custom validation,
> event handling etc.
>
> -t
>
> On Oct 17, 2006, at 9:19 AM, Andy wrote:
>
> > Hi,
> >
> > On Tue, 17 Oct 2006, Ben Gunter wrote:
> >> String id =
> getContext().getRequest().getParameter("id");
> >
> > Generally I feel uncomfortable having to do
> getParameter
> > hacks. The value of id may have come from the
> request
> > parameter, but it may also have come from
> elsewhere (the
> > previous flashed actionbean instance during
> redirect, for
> > example, if using BeanFirstPopulationStrategy).
> >
> > In my real use case there are many more parameters
> being
> > transferred across pages using hidden fields, and
> they form
> > complex objects. A user coming into the view page
> from the
> > search page, upon hitting "exit" from the view
> page, will
> > want to see the same query and the same page of
> the results
> > there (I use Hibernate query-by-example); that is
> even if
> > the user went through a few
> view-edit-view-edit-view cycles.
> >
> > It seems that @DontBind does have its uses, and so
> does
> > @IgnoreBindingErrors. In my case,
> @IgnoreBindingErrors is
> > the one that I need. It seems counterproductive to
> @DontBind
> > and then manually getParameter as above.
> >
> > Andy
> >
> >
>
----------------------------------------------------------------------

>
> > ---
> > Using Tomcat but need to do more? Need to support
> web services,  
> > security?
> > Get stuff done quickly with pre-integrated
> technology to make your  
> > job easier
> > Download IBM WebSphere Application Server v.1.0.1
> based on Apache  
> > Geronimo
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> >
>
https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
-------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
>
https://lists.sourceforge.net/lists/listinfo/stripes-users
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users