[
http://www.stripesframework.org/jira/browse/STS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11604#action_11604
]
Mike McNally commented on STS-638:
----------------------------------
Actually I take it back about "thing.x" and "thing.y" always being overwritten
in the "second case" of the bug description. That will only happen if the form
fields are checkboxes (not impossible of course).
> DefaultActionBeanPropertyBinder incorrectly binds "null" to missing fields
> sometimes
> ------------------------------------------------------------------------------------
>
> Key: STS-638
> URL: http://www.stripesframework.org/jira/browse/STS-638
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Environment: All
> Reporter: Mike McNally
>
> The DefaultActionBeanPropertyBinder, in concert with the "form" tag, sports a
> feature designed to handle the problematic behavior of HTTP "checkbox" and
> (though I understand this one a little less) "select" elements. The form tag
> dumps out a hidden field with a value that comprises a list of the form
> parameters coded on the page. That list is used by the property binder code
> to detect that form field values coded into the actual form are missing from
> the HTTP request parameter map. When that happens, the property binder binds
> a null value into the action bean properties corresponding to each missing
> parameter.
> This behavior is probably useful sometimes, but the code that performs the
> binding does not do it carefully, and can in some cases incorrectly overwrite
> an already-bound non-null property value. Specifically, consider the case
> where an action bean has a bean-valued property called "thing", and the form
> contains three fields: "thing", "thing.x", and "thing.y". The "thing" field
> is a stripes:select tag whose options are name-id pairs of existing instances
> of the "thing" bean type. The "thing.x" and "thing.y" field are (say) simple
> stripes:text tags representing string properties of the "thing" bean type.
> Consider that the form may be intended to allow a user to select either an
> existing "thing" from the select tag, or to create a new thing with
> properties "x" and "y". To achieve that, the form will also have a pair of
> radio buttons set either to "new" - to allow "x" and "y" properties to be
> typed in for a new "thing" - or to "known", which enables the stripes:select
> element and disables "thing.x" and "thing.y". Thus, upon form submission,
> the HTTP request will contain either "thing.x" and "thing.y", OR it will
> contain only an id value for "thing", because client-side code will be
> careful to disable the form elements according to the radio button settings.
> In the former case - the case where the form submits a "thing.x" and a
> "thing.y" - what happens on the server is that the property binder will
> instantiate a "thing" for the action bean, and then set the values of
> "thing.x" and "thing.y" according to the HTTP parameters. It will then check
> the hidden "field manifest" form field and notice that "thing" is missing.
> It will therefore re-set the action bean "thing" property to null, thus
> overwriting the work already done.
> In the latter case - the case where the form submits a "thing" id value from
> the select tag and no values from "thing.x" and "thing.y" - the opposite, but
> equally bad, error will be carried out by the property binder. The action
> bean will be given the instantiated instance of "thing" based on the
> passed-in id value from the HTTP request. Then the code will notice that
> "thing.x" and "thing.y" are missing from the parameter map, so it will bind a
> "null" over the properties in the instantiated "thing" instance.
> I'm not sure how this should be fixed. There's no good workaround in the
> action bean, and I can't figure out a good workaround on the page. For now
> I'm going to create my own property binder class that just doesn't do that
> missing field check at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
