Thank you so much, Shing. The problem was indeed with object equality
in Java. I implemented the methods and now I'm able to retrieve the
values of the model objects on submit.
And thanks Nick, for pointing me to the correct implementation of
using the selection models with custom objects.
Your help is very much appreciated. I am currently using the Dynamic
Selection List instead of the standard PropertySelection.
-waimun
On 8/18/06, Shing Hing Man <[EMAIL PROTECTED]> wrote:
> You might like to try to implemented your own equal
> method in UserDepartment.java.
>
> Shing
>
>
>
> --- Waimun Yeow <[EMAIL PROTECTED]> wrote:
>
> > Yes, indeed the two selection models are suspicious.
> > I used
> > PropertySelection to test DepartmentSelectionModel
> > and the value
> > displayed by @Insert shows the correct value of the
> > selected entry
> > but the list did not generate selected="selected"
> > for the entry after
> > submit and hence fell back to no entries listed as
> > selected="selected". Is that the correct behavior of
> >
> > PropertySelection? I am definitely missing something
> > there. By the
> > way, I am using <binding name="submitOnChange"
> > expression="true" />
> > to test the PropertySelection.
> >
> > -waimun
> >
> > On 8/18/06, Shing Hing Man wrote:
> > > UsersByDepartmentSelectionModel.java (and
> > > DepartmentSelectionModel.jav)
> > > looks suspcious.
> > >
> > >
> > > The UsersByDepartmentSelectionModel.getOption
> > method
> > > returns a value
> > > from userLists, but
> > > UsersByDepartmentSelectionModel.translateValue
> > returns
> > > a value using a dao.
> > >
> > >
> > > You might like to test
> > > UsersByDepartmentSelectionModel in a standalone
> > > PropertySelection
> > > component : select an entry from the drop list.
> > Print
> > > the selected value in a form
> > > listener method.
> > >
> > > Shing
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
