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 <rj...@google.com> 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 <e...@google.com> wrote: >> >> >> On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett <itru...@gmail.com> 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 -~----------~----~----~----~------~----~------~--~---
