> > Thinking outload... > > What about allowing ctors to take a HM. The other ctors use the default > implementation. If you dont care for a HM then use the ctors without HM in > the parameter list. That way
The problem with this is that you then have to add HM to the ctor for every extension of Widget (which are many). > you dont pollute the widget method list with gets/creates and sets Well, I think the current consensus is that gets and sets won't happen/aren't necessary for the use case in question. As far as polluting the Widget method list with createHM()... It is a protected method with a default implementation, so 1) You would have to extend Widget (or one of widget's subclasses) to see it. 2) You probably wouldn't see it unless you were purposefully looking for things to extend about Widget > which prolly dont make sense once the thing is built. Since the HandlerManager is lazy loading (with good reason, too) the only way this sort of flexible API makes sense is to (1) provide a factory method or (2) allow for a HMFactory in the constructor. I tend towards the factory method because it is a less complex change and because of the problems with constructor extensions mentioned above. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
