Home » Modeling » EMF » Revisiting Not persisting the attributes with default values
| Revisiting Not persisting the attributes with default values [message #416952] |
Wed, 20 February 2008 21:12  |
Eclipse User |
|
|
|
Originally posted by: derrydavis.hotmail.com
I have a problem with persisting attributes that are 'required' but no
default values are provided. I've set the
XMLResource.OPTION_KEEP_DEFAULT_CONTENT option to true and the attribute,
name, to the primitive type 'String <java.lang.String>' (according to this
thread
http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 1226.html) but
it does not persist. However setting the type to 'EString
<java.lang.String>' causes it to persist, write to the XML data file.
Is 'String <java.lang.String>' not a primitive type? I expect it to be,
but it's not behaving as expected.
And our model is built in XSD and sets the attribute to a 'string' type.
The import of it into the genmodel selects the 'String <java.lang.String>'
type for the attribute. The requirement to manage our model in XSD will
cause problems each time we do an import. A single change to model would
cause us to update hundreds of attributes of they have to be 'EString
<java.lang.String>'.
Thanks in advance,
-derry
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416954 is a reply to message #416952] |
Wed, 20 February 2008 22:05  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Derry,
Comments below.
Derry wrote:
> I have a problem with persisting attributes that are 'required' but no
> default values are provided. I've set the
> XMLResource.OPTION_KEEP_DEFAULT_CONTENT option to true and the
> attribute, name, to the primitive type 'String <java.lang.String>'
> (according to this thread
> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 1226.html)
> but it does not persist. However setting the type to 'EString
> <java.lang.String>' causes it to persist, write to the XML data file.
> Is 'String <java.lang.String>' not a primitive type?
No. It extends java.lang.Object.
> I expect it to be, but it's not behaving as expected.
Only the types for which there are corresponding wrapper types, e.g.,
int and java.lang.Integer, are primitive.
> And our model is built in XSD and sets the attribute to a 'string'
> type. The import of it into the genmodel selects the 'String
> <java.lang.String>' type for the attribute. The requirement to manage
> our model in XSD will cause problems each time we do an import. A
> single change to model would cause us to update hundreds of attributes
> of they have to be 'EString <java.lang.String>'.
A feature that's marked as required must be set. If you don't give the
feature a default, the above option won't help you. You could use
ecore:default on the feature to specify an Ecore default without
specifying a default in the XSD; XSD won't allow you to give a required
feature a default since required implies the instance must have a
serialized value and hence a default would be pointless...
> Thanks in advance,
> -derry
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416956 is a reply to message #416954] |
Thu, 21 February 2008 00:21 |
| Eclipse User |
|
|
|
Originally posted by: derrydavis.hotmail.com
Welcome back Ed!
Thanks for the info.
Ed Merks wrote:
> No. It extends java.lang.Object.
>> I expect it to be, but it's not behaving as expected.
> Only the types for which there are corresponding wrapper types, e.g.,
> int and java.lang.Integer, are primitive.
Sorry, my Java inexperience is showing.
> A feature that's marked as required must be set. If you don't give the
> feature a default, the above option won't help you. You could use
> ecore:default on the feature to specify an Ecore default without
> specifying a default in the XSD; XSD won't allow you to give a required
> feature a default since required implies the instance must have a
> serialized value and hence a default would be pointless...
This is actually the root of the problem. Consider the case where the
schema defines a required attribute with a min length of 0. Null is valid
value for the attribute and the attribute should be created. But EMF does
not write the attribute to the XML. This creates invalid XML! The schema,
expecting an attribute that is not in the XML, will fail the XML
validation. We could default an empty string into the value, but that's
not the same as no value.
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416958 is a reply to message #416956] |
Thu, 21 February 2008 00:33 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Derry,
If you validate the EMF instance itself (right click on the document
root and invoke Validate...) you'll find it's not a valid instance. If
you serialize an instance that isn't valid before you serialize it, the
serialized result won't be valid either. Consider if the value is a
complex type rather than a simple type. It's not even possible to
define a default. For such a case, you must create a valid instance
object and set it to the feature. So this case for a simple type value
really not different. I.e., you must decide/choose a value and you must
set it. I.e., defining something as being required means you must set a
meaningful value in order to properly specify the instance. If you want
to be "lazy" you can specify the empty string as the feature's default
value and then force such default values to be serialized...
Derry wrote:
> Welcome back Ed!
> Thanks for the info. Ed Merks wrote:
>> No. It extends java.lang.Object.
>>> I expect it to be, but it's not behaving as expected.
>> Only the types for which there are corresponding wrapper types, e.g.,
>> int and java.lang.Integer, are primitive.
> Sorry, my Java inexperience is showing.
>
>> A feature that's marked as required must be set. If you don't give
>> the feature a default, the above option won't help you. You could
>> use ecore:default on the feature to specify an Ecore default without
>> specifying a default in the XSD; XSD won't allow you to give a
>> required feature a default since required implies the instance must
>> have a serialized value and hence a default would be pointless...
> This is actually the root of the problem. Consider the case where the
> schema defines a required attribute with a min length of 0. Null is
> valid value for the attribute and the attribute should be created. But
> EMF does not write the attribute to the XML. This creates invalid XML!
> The schema, expecting an attribute that is not in the XML, will fail
> the XML validation. We could default an empty string into the value,
> but that's not the same as no value.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416959 is a reply to message #416958] |
Thu, 21 February 2008 03:22 |
| Eclipse User |
|
|
|
Originally posted by: derrydavis.hotmail.com
Comments below:
Ed Merks wrote:
> Derry,
> If you validate the EMF instance itself (right click on the document
> root and invoke Validate...) you'll find it's not a valid instance. If
> you serialize an instance that isn't valid before you serialize it, the
> serialized result won't be valid either. Consider if the value is a
Understood and in agreement.
> complex type rather than a simple type. It's not even possible to
> define a default. For such a case, you must create a valid instance
> object and set it to the feature. So this case for a simple type value
Agreed.
> really not different. I.e., you must decide/choose a value and you must
> set it. I.e., defining something as being required means you must set a
> meaningful value in order to properly specify the instance. If you want
I disagree with this (unless you saying this is specific to EMF). As you
probably know XML schema will allow you to define something as required
and not set it to a value. Here is a complex type example:
<complexType name="test">
<attribute name="name" type="string" use="required"></attribute>
<attribute name="id" use="required">
<simpleType>
<restriction base="string">
<minLength value="0"></minLength>
</restriction>
</simpleType>
</attribute>
</complexType>
Attribute id is required but has a minimum lenght of 0, effictively
meaning the attribute is required but does not have to have a value.
So this <test name="" id="String"/> would be valid where as this is not
<test id="String"/> (obviously).
> to be "lazy" you can specify the empty string as the feature's default
> value and then force such default values to be serialized...
Yeap, got that to work.
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416967 is a reply to message #416959] |
Thu, 21 February 2008 12:04 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Derry,
Comments below.
Derry wrote:
> Comments below:
> Ed Merks wrote:
>
>> Derry,
>
>> If you validate the EMF instance itself (right click on the document
>> root and invoke Validate...) you'll find it's not a valid instance.
>> If you serialize an instance that isn't valid before you serialize
>> it, the serialized result won't be valid either. Consider if the
>> value is a
> Understood and in agreement.
>> complex type rather than a simple type. It's not even possible to
>> define a default. For such a case, you must create a valid instance
>> object and set it to the feature. So this case for a simple type value
> Agreed.
>> really not different. I.e., you must decide/choose a value and you
>> must set it. I.e., defining something as being required means you
>> must set a meaningful value in order to properly specify the
>> instance. If you want
> I disagree with this (unless you saying this is specific to EMF). As
> you probably know XML schema will allow you to define something as
> required and not set it to a value. Here is a complex type example:
> <complexType name="test">
> <attribute name="name" type="string" use="required"></attribute>
> <attribute name="id" use="required">
> <simpleType>
> <restriction base="string">
> <minLength value="0"></minLength>
> </restriction>
> </simpleType>
> </attribute>
> </complexType>
> Attribute id is required but has a minimum lenght of 0, effictively
> meaning the attribute is required but does not have to have a value.
> So this <test name="" id="String"/> would be valid where as this is
> not <test id="String"/> (obviously).
The empty string is a value, a string of length zero, only in the second
case is there no value.
>
>> to be "lazy" you can specify the empty string as the feature's
>> default value and then force such default values to be serialized...
> Yeap, got that to work.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416980 is a reply to message #416967] |
Thu, 21 February 2008 18:34 |
| Eclipse User |
|
|
|
Originally posted by: derrydavis.hotmail.com
Hi Ed,
I think I've gotten us too far down into the data and code on this issue.
So I'd like to pull it back up to a high-level and walk through a scenario.
I have 2 legacy systems that I need to share data between. Ive defined a
data model using XML Schema. As far as I know everything has be specified
about the required attribute and is valid syntax/construct from an XSD
standpoint.
I need to generate an EMF editor with property pages as a structured
presentation for user input. Data is being integrated with a third party
system that requires all attributes to be defined, even when there is no
value. This is because the legacy systems have different approaches to the
values and the model needs to be explicit for consistent processing of the
value assignment across the systems.
I would like to use EMF out of the box generated editors to render
(serialize) the XML output with all the attributes defined and set a
default value of empty string when values are not specified by the users.
What is a recommended approach to take with EMF in order to solve this
problem?
Thanks in advance,
-derry
|
|
|
| Re: Revisiting Not persisting the attributes with default values [message #416981 is a reply to message #416980] |
Thu, 21 February 2008 18:54 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Derry,
Comments below.
Derry wrote:
> Hi Ed,
> I think I've gotten us too far down into the data and code on this issue.
I think I helped. :-P
> So I'd like to pull it back up to a high-level and walk through a
> scenario.
>
> I have 2 legacy systems that I need to share data between. I�ve
> defined a data model using XML Schema. As far as I know everything has
> be specified about the required attribute and is valid
> syntax/construct from an XSD standpoint.
Yes, you can declare an attribute as required and that means the XML
instance must have that attribute present with a value, even if it's
just an empty string.
> I need to generate an EMF editor with property pages as a structured
> presentation for user input.
I think see where this is going. Properties pages are kind of sucky and
the distinction between null and empty string is extremely poorly
supported. :-( I don't even see how the newer data binding framework
deals well with it.
> Data is being integrated with a third party system that requires all
> attributes to be defined, even when there is no value.
Yep. In EMF if you have a feature that's required (lowerBound > 0) and
you validate the instance, it will be considered invalid if the value is
not set.
> This is because the legacy systems have different approaches to the
> values and the model needs to be explicit for consistent processing of
> the value assignment across the systems.
>
> I would like to use EMF �out of the box� generated editors to render
> (serialize) the XML output with all the attributes defined and set a
> default value of empty string when values are not specified by the users.
The generated editor support support a validate action. Right click on
the root object within the resource to invoke that. This would help to
alert the user that they have more information to specify. I suppose you
could invoke this automatically before saving and force the user to make
the instance valid before they save.
>
> What is a recommended approach to take with EMF in order to solve this
> problem?
> Thanks in advance,
> -derry
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:53:47 GMT 2024
Powered by FUDForum. Page generated in 0.03667 seconds |
] 
Search
Help
Register
Login
Home
