carmdevol / oryx-editor

Automatically exported from code.google.com/p/oryx-editor
Other
0 stars 0 forks source link

Setters for properties in stencilset JSON file #472

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What is the feature desired?
In order to have more possibilities when the property has changed. 

Here is a hack I made which implements this feature : 
http://ffayolle.dyndns.org/oryx/hack_setter.js.zip
The zip file includes the JS file and an HOWTO (for using it and deploying it).
Please, feel free to include it, and give feedbacks. If you are commiter, I am 
at your disposal to help you to integrate it properly.

Why is this feature important?
To allow developpers do advanced things when a property has changed. For 
example : 
 - to allow changing the view when this property has changed (in my case, I have to change an arrow according to an Integer property). 
 - to force an Integer value to be odd 

Any applications that provide this or a comparable feature?

Please use labels!
setter event property

Original issue reported on code.google.com by florent....@gmail.com on 10 Jun 2011 at 8:40

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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