HasValue<T extends Suggestion> sounds wrong to me. The suggestions are not the value that we're getting from the user, they're prompts to the user to help her get to the actual value. I'd much more expect a SuggestionBox to be HasValue<String> -- it's just a TextBox that happens to have chats with the server. rjrjr
On Tue, Feb 24, 2009 at 7:24 AM, Isaac Truett <[email protected]> wrote: > > I like the super class. I'm not sure it actually needs to be abstract. > I think that by adding HasValue<T> to Suggestion we can do it with > concrete classes. > > TypedSuggestBox<T> (SuggestBoxBase?) > Suggestion<T> implements HasValue<T> > SuggestOracle<T> > SuggestBox extends TypedSuggestBox<String> > MultiWordSuggestOracle extends SuggestOracle<String> > > That should cover my use case and, I think, minimize impact on anyone > using only the plain String suggestions. > > > > > On Tue, Feb 24, 2009 at 10:00 AM, Ray Ryan <[email protected]> wrote: > > How about extracting a parameterized super class: > > AbstractSuggestionBox<T extends Suggestion> > > SuggestionBox extends AbstractSuggestionBox<Suggestion> > > rjrjr > > > > On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher <[email protected]> wrote: > >> > >> > >> On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett <[email protected]> > wrote: > >>> > >>> The API documentation has this to say on the subject: > >>> > >>> "[...] To send back a DTO with each suggestion, extend the Suggestion > >>> interface and define a getter method that has a return value of the > >>> DTO's type. Define a class that implements this subinterface and use > >>> it to encapsulate each suggestion. > >>> > >>> To access a suggestion's DTO when the suggestion is selected, add a > >>> SuggestionHandler to the SuggestBox (see SuggestBox's documentation > >>> for more information). In the > >>> SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method, > >>> obtain the selected Suggestion object from the SuggestionEvent object, > >>> and downcast the Suggestion object to the subinterface. Then, acces > >>> the DTO using the DTO getter method that was defined on the > >>> subinterface." > >>> > >>> See > >>> > http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html > >>> > >>> (the 1.6 version is similar, but with the new event model) > >>> > >>> So the endorsed solution is to extend and cast. Fair enough. This > >>> probably dates from pre-1.5, and it was good enough for then. But is > >>> there a reason not to parameterize SuggestBox with <T extends > >>> Suggestion> (and SuggestOracle<T>, SelectionEvent<T>, etc.) now that > >>> that's an option? Or perhaps make Suggestion implement HasValue<T>? I > >>> have an application that uses many SuggestBoxes and many different > >>> Suggestion subclasses and this would simplify things (and eliminate > >>> much type-casting). > >> > >> I'm not sure parameterizing SuggestBox itself would be worth it, as > most > >> people use it without creating new types of suggestions: so the > >> parameterization would add clutter for the many and prevent casts for > the > >> few. Though, I completely agree it is annoying to have to cast. Perhaps > we > >> could create a composite-based CustomSuggestBox that is parameterized? > >> > >> > >>> > >>> > >>> Any thoughts on this? Horrible side effects that I'm missing? > >>> > >>> - Isaac > >>> > >>> > >> > >> > >> > >> -- > >> "There are only 10 types of people in the world: Those who understand > >> binary, and those who don't" > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
