The work-around of setting the secure parameter to "false" works for me (if
I do it on *all* the selects in the form).
The issue was caused by the fix for TAP5-2179 ("The Select component can be
hacked to select a value not in the SelectModel").
I agree with Lance that the secure parameter's default should be changed to
false, because 1) defaulting to "true" is a breaking change, 2) I'm not
sure TAP5-2179 was really a significant problem for most apps, and 3) there
are significant performance implications. (Requiring the SelectModel to
exist when the form is submitted either requires a (potentially large) list
of objects to be persisted in the session or a (potentially large) list of
objects to be recreated from a database query.)
Anybody else have an opinion on this?
On Wed, Oct 16, 2013 at 10:03 AM, George Christman
<gchrist...@cardaddy.com>wrote:
> filed jira issue
>
> https://issues.apache.org/jira/browse/TAP5-2204
>
>
> On Wed, Oct 16, 2013 at 10:03 AM, George Christman
> <gchrist...@cardaddy.com>wrote:
>
> > It's still failing with secure="false", the only way to get it to work is
> > to @Persist SelectModel computerModels.
> >
> > btw, the onValueChanged method in my above example should be
> > onValueChangedFromComputer.
> >
> >
> > On Wed, Oct 16, 2013 at 9:38 AM, Lance Java <lance.j...@googlemail.com
> >wrote:
> >
> >> It seems like a new 'secure' parameter has been added to select which
> >> defaults to true (value must exist in the model).
> >>
> >> Try setting secure="false"
> >>
> >> I think this should be the default to maintain backwards compatibility.
> >>
> >
> >
> >
> > --
> > George Christman
> > www.CarDaddy.com
> > P.O. Box 735
> > Johnstown, New York
> >
> >
>
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
