Home » Modeling » EMF » EMF tree editor and serialization don't honor unsettable=true
| EMF tree editor and serialization don't honor unsettable=true [message #507722] |
Thu, 14 January 2010 13:28  |
Dennis Hendriks
Messages: 74
Registered: January 2010
Location: The Netherlands |
Member |
|
|
I have an Ecore model X with a class Y and an attribute Z that is optional (lower bound 0, upper bound 1). It is of EType 'Boolean [boolean]'. I created a genmodel for the ecore and generated all code (edit/editor/tests).
Now I start the editor as Eclipse application, create a project, add a new X model, and open it in the X language tree editor that I generated using the genmodel. I create an instance of the Y class. I open the Properties window and try to change the Z attribute. It has value 'false' by default, and I can only set it to 'true' or 'false'. I would have expected to be able to set it to 'undefined' or '', since it is optional.
I read something about the Advanced property 'Unsettable', so I changed the attribute to unsettible=true, regenerated all the code etc, and started the editor again. The attribute could still only be set to 'true' or 'false'.
The same as for the boolean attribute, goes for attributes of enumeration types. I can only set it to enumeration literals, not to undefined or unset or whatever it is called.
Also, when serialized, the default value of an attribute does not result in an XML attribute. I would expect the default value to result in an XML attribute, and I would expect no XML attribute only in case the (ecore) attribute is unset.
The two problems appear to be related (to me anyway).
Does anyone know how to make attributes truly optional? Any help would be greatly appreciated.
I use eclipse-modeling-galileo-SR1-incubation-linux-gtk.tar.gz as my Eclipse version.
[Updated on: Thu, 14 January 2010 13:29] Report message to a moderator |
|
|
| Re: EMF tree editor and serialization don't honor unsettable=true [message #507733 is a reply to message #507722] |
Thu, 14 January 2010 13:59  |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Dennis,
The property view is very poor in general and poor at showing things
like implicit defaults verses actual set values. There is a Restore
button that will unset the value; it would be nice if the enablement of
that button reflected the unset state, but the APIs don't support that.
It's hard to change the state from unset to being set with the default
value; yet another annoying aspect.
You should notice a distinction in the serialization between the
attribute/element be absent, verses it being present with a value.
Making things unsettable adds an additional state represented as an
additional boolean flag/field in the generated Impl. You can query that
state with eIsSet. Generally only things for which eIsSet is true will
serialize.
D. Hendriks (Dennis) wrote:
> I have an Ecore model X with a class Y and an attribute Z that is
> optional (lower bound 0, upper bound 1). It is of EType 'Boolean
> [boolean]'. I created a genmodel for the ecore and generated all code
> (edit/editor/tests).
>
> Now I start the editor as Eclipse application, create a project, add a
> new X model, and open it in the X language tree editor that I
> generated using the genmodel. I create an instance of the Y class. I
> open the Properties window and try to change the Z attribute. It has
> value 'false' by default, and I can only set it to 'true' or 'false'.
> I would have expected to be able to set it to 'undefined' or '', since
> it is optional.
> I read something about the Advanced property 'Unsettable', so I
> changed the attribute to unsettible=true, regenerated all the code
> etc, and started the editor again. The attribute could still only be
> set to 'true' or 'false'.
>
> The same as for the boolean attribute, goes for attributes of
> enumeration types. I can only set it to enumeration literals, not to
> undefined or unset or whatever it is called.
>
> Also, when serialized, the default value of an attribute does not
> result in an XML attribute. I would expect the default value to result
> in an XML attribute, and I would expect no XML attribute only in case
> the (ecore) attribute is unset.
>
> The two problems appear to be related (to me anyway).
>
> Does anyone know how to make attributes truly optional? Any help would
> be greatly appreciated.
>
> I use eclipse-modeling-galileo-SR1-incubation-linux-gtk.tar.gz as my
> Eclipse version.
>
>
>
>
>
>
> eclipse v?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF tree editor and serialization don't honor unsettable=true [message #508050 is a reply to message #507935] |
Fri, 15 January 2010 16:37 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Dennis,
Comments below.
D. Hendriks (Dennis) wrote:
> Thanks for your reply. I tested the serialization with the tree editor
> and property view, where I couldn't unset anything. I now tested it
> with an ATL transformation I was working on, and indeed there is a
> difference between unset and default value. It works.
>
> Are there any plans to fix the property view (and API?) to properly
> handle optional values and unsettable values? Is there a bug ticket
> for this?
No, I don't think there are such plans. I've never requested changes in
the platform. The EEF project will produce nicer dialog views, but this
distinction between whether a given value is a default verses explicitly
set seems to be poorly supported no matter what dialog form is being
used. Even data binding deals poorly with it and with things like how
to represent null verses the empty string. After a while I throw up my
hands when no one seems to think a general solution would be a good thing.
>
> I also wonder why the unsettable is needed at all. If I declare a
> boolean attribute to be optional (lower bound 0, upper bound 1), I
> think there should always be a difference between unset and set
> (whether with default value or otherwise).
It depends on whether you think there are only two states or more. In
the XML the attribute can be x="true" x="false" or can be missing.
That's three different states. A single Boolean can't represent all
those...
> If however I have a non optional attribute (lower bound 1, upper bound
> 1), I can imagine that it would be useful to have an advanced
> 'dontSerializeIfDefaultValue' attribute. Does this make sense?
If it's required you should expect it to always be present, but whether
that means in the serialization or in the model is tricky. And of
course whether you're dealing with primitives or objects makes a
difference. If you have objects, you can always use null.
> Would this be something that could be implemented?
I'm not sure what "this" is yet. There's already a bit too much
subtlety and complexity in this area, so I'd be reluctant to add more.
>
> Does all of this have anything to do with SDO (or SDO versions), as
> described here: http://issues.apache.org/jira/browse/TUSCANY-1093 ?
> Does EMF even use SDO? If so, what version?
SDO used EMF. We terminate the SDO component at Eclipse though.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF tree editor and serialization don't honor unsettable=true [message #508259 is a reply to message #508050] |
Mon, 18 January 2010 07:38 |
Dennis Hendriks
Messages: 74
Registered: January 2010
Location: The Netherlands |
Member |
|
|
Thanks again for your reply.
> After a while I throw up my
> hands when no one seems to think a general solution would be a good thing.
I think it would be a good thing, so that makes at least two of us 
> It depends on whether you think there are only two states or more.
I think that it would seem obvious that if you have an OPTIONAL boolean, that you have three states, and that if you have a NON-OPTIONAL boolean, you have three states. Isn't that obvious? Conceptionally, I can't see how anyone could disagree. Implementation-wise, serialization-wise, etc, it may be less obvious, but on a conceptional level, I think it can be seen in only one way.
> Even data binding deals poorly with it and with things like how
> to represent null verses the empty string.
An optional string attribute, would, have the possibility of having 'value' null, while a non-optional one would not. Both could have the empty string as value, as it is a valid string value. It seems really simple to me?
> If you have objects, you can always use null.
I would only expect a null value to be allowed, if the attribute is OPTIONAL.
Dennis
|
|
|
| Re: EMF tree editor and serialization don't honor unsettable=true [message #508392 is a reply to message #508259] |
Mon, 18 January 2010 16:04 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Dennis,
Comments below.
D. Hendriks (Dennis) wrote:
> Thanks again for your reply.
>
>> After a while I throw up my
>> hands when no one seems to think a general solution would be a good
>> thing.
>
> I think it would be a good thing, so that makes at least two of us :)
It would seem obvious would it not.
>
>> It depends on whether you think there are only two states or more.
>
> I think that it would seem obvious that if you have an OPTIONAL
> boolean, that you have three states, and that if you have a
> NON-OPTIONAL boolean, you have three states. Isn't that obvious?
Unfortunately optionality and unsettability are two different things.
> Conceptionally, I can't see how anyone could disagree.
> Implementation-wise, serialization-wise, etc, it may be less obvious,
> but on a conceptional level, I think it can be seen in only one way.
That works fine for something where there is an enumerated set of
choices, but how does that work for int say? Or for String?
>
>> Even data binding deals poorly with it and with things like how
>> to represent null verses the empty string.
>
> An optional string attribute, would, have the possibility of having
> 'value' null, while a non-optional one would not.
Though you'd still have to deal with the case were it started null.
After all, things typically start in the ground state that might well
not be valid.
> Both could have the empty string as value, as it is a valid string
> value. It seems really simple to me?
>
>> If you have objects, you can always use null.
>
> I would only expect a null value to be allowed, if the attribute is
> OPTIONAL.
Yes, though your case was dealing with primitives which can't be null.
>
>
> Dennis
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:37:53 GMT 2024
Powered by FUDForum. Page generated in 0.03127 seconds |
] 
Search
Help
Register
Login
Home
