Well put, RayC, thanks. MVC is exactly the intended point of HasValue.
(Freeland, John, it's HasValue<T>, that's not being debated, fret ye not.)
And you guys are right, I think, that we're wrong to paralyze ourselves with
fears of future confusion with our still-vague-but-crystallizing-nicely
notions of a data binding framework.
The specific issue that got me to lob this grenade was a disgusted internal
complaint by someone who has long been frustrated by our CheckBox's lack of
access to the dom value field. When he saw the longed for method appear and
do exactly the wrong thing, and in a manner redundant with isChecked...
I like HasValue, but its application to CheckBox has produced very confusing
little beastie. So, how about we narrow the scope of this conversation to
CheckBox api repair. How about this:
- Deprecate CheckBox#isChecked and CheckBox#setChecked
- Introduce CheckBox#setFormValue
- Add copious javadoc to compare and contrast the two set...Value methods
If this flies, are there other widgets that need the setFormValue method?
rjrjr
On Fri, Dec 12, 2008 at 7:42 AM, Ray Cromwell <cromwell...@gmail.com> wrote:
>
> IMHO, the concept of a Widget having a value is that it has only one
> value. The "value" can certainly be an object with multiple fields, or
> with conversion helper functions (String->Boolean), but it's one value
> with a normalized internal representation.
>
> For example, consider an USPostalAddressWidget, which
> HasValue<USPostalAddress>. This widget is quite complex, with probably
> ample internal textboxes for each field (street, city, state, zip,
> suite, etc) and also validation. However, the widget conceptually has
> a single value: a USPostalAddress that can be get and set.
>
> In this context, I think it is clear that HasValue is really a
> Model-View interface. If it were a Table, it would be
> HasValue<TableModel> or HasValue<TableData>, for example. Probably the
> primary difference is HasValue doesn't require models to provide
> change listener interfaces.
>
> I don't believe that Data Binding and Model/View architectures are
> mutually exclusive. The main difference is, with MVC, typically, you
> build model POJOs, and build the View to be tightly coupled to the
> model interface, so that there is usually (but not always) a one to
> one correspondence between View and Model types. With Data Binding
> frameworks, the coupling is looser and you can have a many-to-one
> relationship, e.g bind POJO.fooField to Widget A and bind
> POJO.barField to WidgetB, or further, you can bind into composite
> widgets exposing their innards. Data Binding allows for more reuse
> since you can repurpose pojo models by slicing and dicing them with
> binding expressions, on the other hand, lots of bindings can get messy
> and make it harder to track what widgets deal with what data,
> especially if the bindings are dynamic or in a DSL.
>
> -Ray
>
>
> On Thu, Dec 11, 2008 at 11:49 AM, Isaac Truett <itru...@gmail.com> wrote:
> >
> > At the risk of seeming to hand-wave that problem away, I would say
> > that any Widget seeking to implement HasValue twice is not a candidate
> > for HasValue at all. HasValue is, by definition, for Widgets with a
> > single distinct value. The value of a CheckBox is either a String or a
> > Boolean (we've seen arguments either way) or it simply isn't a
> > HasValue because it's a complex Widget with two equally important and
> > independent values.
> >
> >
> > On Thu, Dec 11, 2008 at 2:41 PM, John Tamplin <j...@google.com> wrote:
> >> On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott
> >> <gwt.team.fabb...@gmail.com> wrote:
> >>>
> >>> To be fair, my friend was extending TextBox---which came to implement
> >>> HasValue, and thus acquired the colliding String getValue()---when he
> should
> >>> have extended Composite (which doesn't) instead; that was my suggested
> >>> resolution for him. He grumbled ("but it 'is-a' TextBox, that should
> be
> >>> extends"), but conceded.
> >>> However, the "old" HasValue is not parameterized, and implies something
> >>> has *string* value, period. As applied to CheckBox, that's
> >>> confusing-to-wrong.
> >>> Isaac is correct that we can resolve this by making CheckBox not a
> >>> HasValue, and keep the interface... but the discussion makes me think
> that
> >>> HasValue<T> has merit, and for example a CheckBox would be
> HasValue<Boolean>
> >>> and a TextBox would be HasValue<String> (my friend should still make
> >>> Composites, with HasValue<TelephoneStationNumber>, and not extend
> TextBox).
> >>> But if we go with HasValue (unparameterized), that's a breaking change
> to
> >>> make later (I guess we'd have to make HasTypedValue<T> instead, and
> have
> >>> HasValue come to extend HasTypedValue<String>), and so I'm still happy
> to
> >>> pause and think a bit more.
> >>> (Do we like HasValue<T>, where T is widget-specific for whatever
> widgets
> >>> have values??)
> >>
> >> One problem is that due to type erasure you cannot implement multiple
> copies
> >> of this interface (such as HasValue<Boolean> and HasValue<String>). For
> a
> >> hypothetical checkbox, you might well want a boolean value for checked
> or
> >> not, as well as the string value (ie, what it would post as in a form
> >> submit).
> >>
> >> Other than that, I think the generic version is the way to go if it is
> kept.
> >>
> >> --
> >> John A. Tamplin
> >> Software Engineer (GWT), Google
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
