[See http://jira.openlaszlo.org/jira/browse/LPP-3002]
In the default event system, what you get if you don't write a custom
setter, sends an event every time you call setAttribute. It does
_not_ make any optimization to not send events if you happen to set an
attribute to a value it already has. So my contention is, this is the
expected behavior, and you have to make a really good case for
anything else.
Currently, when you write a custom setter, responsibility for sending
the event falls to you, the setter writer. I have always thought that
this was a bad default, because, while it gives you the ability to
fine-tune exactly when (if ever) the event is sent, it is much more
likely that you just forget to send the event, and you break
everyone's expectations. If you poke around Jira, you will see many
bugs of the form "setting foo does not send the onFoo event".
Invariably, these are from broken custom setters where the setter
writer forgot about the event part of the setter's contract.
It would be really hard for the compiler to analyze your setter code
to discover that you had forgotten to send an event, so my proposal
for how to fix this common error is:
1) If you write a setter in the open tag of an attribute, the event is
always sent (you don't get to control the sending of the event).
E.g., if I say:
<attribute name="foo" setter="this._fooState = foo" />
the compiler will automatically append `this.sendEvent('onfoo', foo)`
to the setter body. (How many places in your code have you written
these shorthand setters and actually remembered that you need to send
an event too?)
2) If you _must_ get control over the sending of the event, you have
to ask for it, and use the long-hand <setter> tag. E.g.:
<setter name="foo" args="newFoo" event="false">
...
if (<i really want to send the event>) this.sendEvent('onfoo',
newFoo);
</setter>
This would be an API change, but I think would improve the reliability
of our system overall.
Comments?
