Re: Firing a ChangeEvent from a widget that wouldn't natively fire one

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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.