i was seeing it just as a component that's completely consistent for
selecting among available values.  but if the model is null (required
validation would fail), you could manually pick up the value the user 
entered to create a new object.  the only problem there is clearing
the required validation error.  i don't know.  i don't care too much 
about this one.  was just trying to elucidate what martijn wanted...


igor.vaynberg wrote:
> 
> but that is so disjointed.
> 
> for example how will that interact with setrequired(true)? you entered
> something into text but the model is null?!?
> 
> also
> 
> lets say i want to create a new person if one doesnt exist. if i know this
> field works with strings only there is one thing for me to do, write a
> model
> decorator that does the conversion.
> 
> if it will work the way you want then when they enter something valid
> there
> is no work for me to do, but when they dont i have to do the conversion.
> 
> which one is easier? i would say doing the conversion yourself always is
> easier because its more consistent.
> 
> i guess maybe what we want here is a _different_ component that limits
> your
> choices to only the ones available. in that case it would make sense to do
> the conversion.
> 
> -igor
> 
> 
> On 2/27/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> the model is the object when it's a valid entry.  the text is available
>> through getInput() when it's not.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > but what good is it if the model is set to null when that entered text
>> is
>> > still a valid entry? how does the user then get that entered text? why
>> > isnt
>> > the text the model?
>> >
>> > thats why it is the way it is - working with strings only.
>> >
>> > -igor
>> >
>> >
>> > On 2/27/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> i said that.   "If it can't find it, the model is set to null."
>> >>
>> >> the difference from a "combobox" being that you can find the thing
>> >> they picked that didn't match with getInput().  this makes it
>> essentially
>> >> an editable dropdown.
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > its a combobox, what if they submit text that is not part of any
>> >> existing
>> >> > selection?
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On 2/26/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> Don't you think it should work the same as other list selection
>> >> >> components?
>> >> >> You give the component a list of objects to choose between using
>> the
>> >> text
>> >> >> completion field and when the text is submitted, it sets the model
>> of
>> >> the
>> >> >> component to the first object in the list that matches the text. 
>> If
>> >> it
>> >> >> can't find it, the model is set to null.  If the list of objects
>> are
>> >> in
>> >> >> sorted order by their text, a binary search can be performed for
>> the
>> >> >> model
>> >> >> object.
>> >> >>
>> >> >> If the text isn't unique, how is the user going to choose between
>> two
>> >> >> "Frank
>> >> >> Johnsons"?  I think the text has to be unique to complete like
>> this.
>> >> >>
>> >> >>
>> >> >> Martijn Dashorst wrote:
>> >> >> >
>> >> >> > I want to use the ACTF in our projects, but it is not very
>> helpful
>> >> for
>> >> >> > selecting objects. Typically the text you display for
>> >> >> > selecting a person is not very unique or identifying for the
>> object
>> >> >> > that is associated: "Johnson, Frank" is perfect for display,
>> >> >> > but is hard to dissect when you have to re-assemble the person on
>> >> the
>> >> >> > server side: the ACTF uses a String as the model.
>> >> >> >
>> >> >> > I was thinking of a panel with the autocomplete text field which
>> >> shows
>> >> >> > the display value, and a hidden field that will hold the ID
>> >> >> > of the selected object. The hidden field can then be used to
>> fetch
>> >> the
>> >> >> > object on the server and assign it to the model object of
>> >> >> > ObjectAutoCompleteTextField.
>> >> >> >
>> >> >> > <wicket:panel>
>> >> >> > <input type="text" wicket:id="displayvalue" />
>> >> >> > <input type="hidden" wicket:id="idvalue" />
>> >> >> > </wicket:panel>
>> >> >> >
>> >> >> > The OACTF would need to communicate both the selection markup,
>> and
>> >> the
>> >> >> > associated ID values that need to be set on the hidden
>> >> >> > field upon selection. Now I could add a special tag to the
>> selection
>> >> >> > markup, something like below:
>> >> >> >
>> >> >> > <ul>
>> >> >> >       <li choiceid="12341">Johnson, Frank</li>
>> >> >> >       <li choiceid="41231">Miller, Frank</li>
>> >> >> > </ul>
>> >> >> >
>> >> >> > But I imagine other possibilities are available (or using the
>> markup
>> >> >> > id itself).  Can you share your thoughts?
>> >> >> >
>> >> >> > Martijn
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Learn Wicket at ApacheCon Europe: http://apachecon.com
>> >> >> > Join the wicket community at irc.freenode.net: ##wicket
>> >> >> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
>> >> >> > http://wicketframework.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Object-oriented-AutoCompleteTextField-tf3294592.html#a9175997
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Object-oriented-AutoCompleteTextField-tf3294592.html#a9185833
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Object-oriented-AutoCompleteTextField-tf3294592.html#a9186041
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Object-oriented-AutoCompleteTextField-tf3294592.html#a9186448
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Reply via email to