Jens,
Thanks for the comments ... See below
On Saturday, December 14, 2013 8:42:06 AM UTC-5, Jens wrote:
>
> Is there any reason to be concerned about firing a ChangeEvent from a
>> composite based on a FlowPanel?
>>
>> I'm trying to track user edits within a form, in order to set a dirty
>> data flag. Sometimes the form has subforms, each of which has it's own
>> data dirty tracking. Basically, I'm handling ChangeEvents and
>> ValueChangeEvents within the subform, and when those occur, I'm firing a
>> ChangeEvent from the subform. It all seems to work, but I have a vague
>> discomfort with it, knowing that things like textboxes and selects natively
>> fire change events, but div tags don't. Is all the event management
>> related to manually fired change events done entirely in GWT?
>>
>
> Not sure if that has any bad consequences but I would guess it does not.
> Maybe some old IE's have bugs regarding event bubble'ing for change events.
>
That was one of my main concerns. It works in IE10s emulation of IE8, but
I've found that that emulation is far from perfect. Some things work in it
that don't work in a real IE8. Fortunately, I'm not concerned with earlier
IE.
>
> However, as dirty tracking is a logical thing I would fire a logical event
> and not a DOM event. I think I would have created a
> DirtyEvent/FormEditedEvent + Handler. Alternatively you could also create
> an interface DirtyTracker that has some methods like
> setDirty(Form/IsWidget) and have the top most class that controls your form
> hierarchy handle the dirtiness of all forms (you would pass the
> DirtyTracker down the Form hierarchy, and each form would call
> setDirty(this) if it detects that it is dirty).
>
I'm actually going to fire an event like that from the panel containing all
the widgets, but need to know when to do that. And, what I'm writing is a
sort of framework to simplify things for folks writing the view classes, so
the abstract base view has:
protected void setChangeHandler(HasChangeHandlers ... widgets)
{
for (HasChangeHandlers widget : widgets)
{
widget.addChangeHandler(dataChangeHandler);
}
}
and they can just pass it a list of widgets
I may end up switching that to use ValueChangeHandlers instead, since
> almost every data widget fires them. But, ListBox doesn't implement
> HasValueChangeHandlers, because it has no concept of value. But, I already
> extend ListBox to give it setValue and getValue for strings, so I can fire
> a ValueChangeEvent<String>. But, where that leaves me uncomfortable is
> that I don't consider that my subforms' overall concept of a value have
> changed, If they did, then I'd have to grab the value of the bean every
> time one field changed in order to supply a value with the event, or turn
> the change handling off after the first invocation makes it dirty, and then
> turn it back on again if the form is reset, or newly populated. Or, I'd
> have to implement firing the data dirty event from the subforms as well,
> which might be the best way to go. But, then the subforms in the main view
> need to be treated separately from the plain widgets, so I'd need two
> methods like the above, and users would have to invoke both, separating
> their components into widgets vs subforms.
>
I also tried writing an overload of the above method using
HasValueChangeHandlers ..., but that isn't distinguishable from the first
version, according to the compiler.
I suppose another approach would be to use Widget ..., and then test what
the item is an instanceof. But then what to do if an item isn't either one
- ignore it, or throw an exception?
This is one place where it would be nice to have mixins - so I could just
add some more logic to things like ValueBoxBase to fire my own custom value.
>
> As an aside, it's a little weird that ListBox fires ChangeEvent, and not
>> ValueChangeEvent, while ValueListBox fires ValueChangeEvent but not
>> ChangeEvent, given that they're both based on select tags.
>>
>
> They serve different purpose. ListBox is the direct wrapper of the select
> tag while ValueListBox works on a higher level as it can deal with any kind
> of values not just strings. The fact that ValueListBox uses a ListBox
> internally is an implementation detail.
>
I can see that, I guess what baffles me is why ListBox doesn't fire
ValueChangeEvent<String>, or ValueChangeEvent<Integer>
And, on a related note, it seems weird to me that many of the ValueBoxBase
classes don't have a primary style, so that, for example, a TextBox looks
different than an IntegerBox
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
