Open GoogleCodeExporter opened 8 years ago
Hey Florent,
I looked into your zip. It seems like you need a pre-change event with a
veto-option and in the stencilset for each property an own setter-event.
Concerning the veto-event, I think we can easily adapt it, but I am not sure
how intuitive it is. Each event listener will be able to change the result
(veto-value) and it is not guaranteed that another listener will change this
value again.
Concerning the setter-event, why is it not enough to just create a
PROPERTY_ABOUTTOCHANG event type?
Cheers,
Phil
Original comment by philipp....@student.hpi.uni-potsdam.de
on 10 Jun 2011 at 9:58
Hi Philipp,
Thank you for your answer.
The advantage of my "setter" idea would be that you could apply this setter to
several attributes, and avoid to check the property name that has changed in
the handler (so it should be more optimized).
> Concerning the veto-event, I think we can easily adapt it,
> but I am not sure how intuitive it is. Each event listener will be able to
change
> the result (veto-value) and it is not guaranteed that another listener will
change
> this value again.
Perhaps we could add the function event.preventDefault() and
event.stopPropagation() like in DOM ? What do you think ?
I have just seen that the EVENT_PROPERTY_CHANGED event exists. But this event
does not include event.shape, the owner of the property. I think including
event.shape would allow to do more things to pluggin developpers.
I don't know which of these ideas is the best. What do you think ? :)
Original comment by florent....@gmail.com
on 10 Jun 2011 at 12:03
Hi Florent,
sorry for the delay.
I thought about it and I believe that an Veto-mechanism will be too much. It
should be enaugh to change the value afterwards to prevent "hiddem" changes for
other plugins. (One plugin changed to X, event is thrown, one plugin changed by
veto Y, another pluggin would have changed this Y (not the X) as well but get
not informed)
The setter would be a minor advantage because the check for a event.type anyway
small effort and property setters are not thrown so frequently (in my
experience).
To include the shape into the event would be no effort to implement and could
give more opportunities. So, why not?
Cheers,
Phil
Original comment by philipp....@student.hpi.uni-potsdam.de
on 13 Jun 2011 at 4:35
Hi Philipp,
OK for me if you include the shape into EVENT_PROPERTY_CHANGED.
Cheers,
Florent
Original comment by florent....@gmail.com
on 13 Jun 2011 at 5:05
Hi Philipp,
Could you do it as soon as possible please ? I really need that feature.
Original comment by florent....@gmail.com
on 24 Jun 2011 at 8:50
Original issue reported on code.google.com by
florent....@gmail.com
on 10 Jun 2011 at 8:40