doSave Implementation in ResourceImpl missing [message #408375] |
Tue, 10 April 2007 12:09 |
Eclipse User |
|
|
|
Originally posted by: h.breuer.fsp-gmbh.com
Hi,
I'm missing a doSave Implementation in my XYResourceImpl class. I have
generated a model from an XSD without Interfaces, only the core classes
were generated. In debug-mode of my application (stand-alone loading and
saving of an xml-stream) I saw that there was a doLoad-method in my custom
XYResourceImpl but no doSave-Implementation from XMLResource.
I wonder why? When is it useful to overwrite it? Is it possible to
generate it too?
Thx
Holger
|
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408379 is a reply to message #408376] |
Tue, 10 April 2007 12:35 |
Eclipse User |
|
|
|
Originally posted by: h.breuer.fsp-gmbh.com
Ed,
I'm working with EMF during the last three months, genertaing test code
and impls and so on. This is my generated XYResourceImpl without a
doSave-Method. Maybe it's only a property to set?
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public static final String copyright = "";
/**
* Creates an instance of the resource.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @param uri the URI of the new resource.
* @generated
*/
public XYResourceImpl (URI uri)
{
super(uri);
}
/**
* A load option that turns of the use of the generate data converters.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public static final String OPTION_USE_DATA_CONVERTER =
"USE_DATA_CONVERTER";
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void doLoad (InputStream inputStream, Map options)
throws IOException
{
...
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void doLoad (InputSource inputSource, Map options)
throws IOException
{
...
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected static final XMLParserPool parserPool = new
XMLParserPoolImpl();
/**
* Loads an instance from the input...
*/
public static EObject load (InputSource inputSource, Map features, Map
properties,
boolean useLexicalHandler)
throws IOException
{
...
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public final static class FrameFactory
...
In the test classes there are only methods which loads and save xml for
the underlying model. If there is no subclass which overrides the doSave
method the default one from XMLResourceImpl is called.
I wonder why you said, that there must be a doSave method in my generated
class?
Holger
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408380 is a reply to message #408379] |
Tue, 10 April 2007 12:52 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Holger,
This generated class extends XMLResourceImpl which has all the doSave
methods implemented so there is no need to generate overrides. So the
lack of generated doSave methods is intentional. I though you were
saying that this method was simply not implemented at all and hence save
wasn't working.
The data converters patten is largely experimental for generating a very
fast deserializer. It's not very complete and there may be all kinds of
cases it won't handle properly for more complex schemas. As such, the
data converters pattern is not highly recommended, but may be useful and
efficient for simpler schemas.
Holger Breuer wrote:
> Ed,
>
> I'm working with EMF during the last three months, genertaing test
> code and impls and so on. This is my generated XYResourceImpl without
> a doSave-Method. Maybe it's only a property to set?
>
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public static final String copyright = "";
>
> /**
> * Creates an instance of the resource.
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @param uri the URI of the new resource.
> * @generated
> */
> public XYResourceImpl (URI uri)
> {
> super(uri);
> }
>
> /**
> * A load option that turns of the use of the generate data converters.
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public static final String OPTION_USE_DATA_CONVERTER =
> "USE_DATA_CONVERTER";
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public void doLoad (InputStream inputStream, Map options)
> throws IOException
> {
> ...
> }
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public void doLoad (InputSource inputSource, Map options)
> throws IOException
> {
> ...
> }
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> protected static final XMLParserPool parserPool = new
> XMLParserPoolImpl();
>
> /**
> * Loads an instance from the input...
> */
> public static EObject load (InputSource inputSource, Map features,
> Map properties,
> boolean useLexicalHandler)
> throws IOException
> {
> ...
> }
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public final static class FrameFactory
>
> ...
>
>
> In the test classes there are only methods which loads and save xml
> for the underlying model. If there is no subclass which overrides the
> doSave method the default one from XMLResourceImpl is called.
>
> I wonder why you said, that there must be a doSave method in my
> generated class?
> Holger
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408385 is a reply to message #408380] |
Tue, 10 April 2007 14:46 |
Eclipse User |
|
|
|
Originally posted by: h.breuer.fsp-gmbh.com
Ed,
you said it is better not to use DataConverters. If I set this property to
false, neither a doSave nor a doLoad method is generated so the load-call
results in an exception.
In addition no create-Methods for my simple-xsd-types are generated, only
createFromString() methods.
I need to set the following properties to true:
Data Type Converters: true
Initilaize by Loading: true
Otherwise I can not instantiate my model during loading a xml-resource.
Is there another possibility to generate create and doLoad-methods?
Holger
|
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408408 is a reply to message #408387] |
Wed, 11 April 2007 08:06 |
Eclipse User |
|
|
|
Originally posted by: h.breuer.fsp-gmbh.com
Ed,
thanks in advice for your help.
The stack trace is not reproducable because of running the app on a
websphere server and struggling with some other problems. Nevertheless I
need the data-converters options because our customers want to code their
model theirselves. Therefore they have to use the create-methods with only
one string-argument:
XYFactory xyFactory = XYFactory.eINSTANCE;
XYType xy = xyFactory .createXYType();
xy.setName (xyFactory.createXYSimpleDataType("1234"));
Dependencies to Ecore should be less and I think the option without
converters is not passable for us.
Please could you tell me detailed problems occurring with this option, if
any?
Further problems should be discussed in another thread ... I'll surley
open shortly a new one :-)
Thx
Holger
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408411 is a reply to message #408408] |
Wed, 11 April 2007 12:04 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Holger,
All the XML Schema data types extend the ones in the schema for
schemas. As such, the create/convert methods in
XMLTypeFactory.eINSTANCE will be sufficient to create any type of data
value, unless you are hand coding additional data types using
ecore:instanceClass annotations on <simpleType>s. And even in such
cases, programmatically constructing the value from a string literal,
e.g., XMLTypeFactory.eINSTANCE.createInt("0") is not as efficient as
just using the Java literal 0 directly. So I'm having a hard time
imagining how having the explicit data converters are necessary and are
better than creating the data value directly in the "normal Java way".
That being said, we would certainly consider a bugzilla feature
enhancement request to specify the use of data converters in the factory
as a separate property from the current one to generate a data
converter-based resource implementation. (As a workaround, if you need
data converters in the factory but don't need the resource
implementation, you can mark the resource impl's class with @generated
NOT, delete all the stuff so that it looks just like the version
generated without data converters, and because of the @generated NOT on
the class, the file will not be touched during regeneration.)
Given that the XMLResourceImpl is already capable of reading and writing
a conforming XML instance, I'm not sure I understand your customers need
to "code their model themselves". Are you really saying they have a
deep seated desire to write their own deserialization and serialization
code despite the fact there is no actual need for that? The generated
data converter resource implementation wouldn't handle things like
mixed text, xsi:type, xsi:nil, or wildcards.
Holger Breuer wrote:
> Ed,
>
> thanks in advice for your help.
>
> The stack trace is not reproducable because of running the app on a
> websphere server and struggling with some other problems. Nevertheless
> I need the data-converters options because our customers want to code
> their model theirselves. Therefore they have to use the create-methods
> with only one string-argument:
>
> XYFactory xyFactory = XYFactory.eINSTANCE;
> XYType xy = xyFactory .createXYType();
> xy.setName (xyFactory.createXYSimpleDataType("1234"));
>
> Dependencies to Ecore should be less and I think the option without
> converters is not passable for us.
>
> Please could you tell me detailed problems occurring with this option,
> if any?
> Further problems should be discussed in another thread ... I'll surley
> open shortly a new one :-)
>
> Thx
> Holger
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: doSave Implementation in ResourceImpl missing [message #408420 is a reply to message #408411] |
Wed, 11 April 2007 14:01 |
Eclipse User |
|
|
|
Originally posted by: h.breuer.fsp-gmbh.com
Ed,
thanks for the hint with the dataConverters.
Our customers don't want to write their own deserialization and
serialization code. That is our part. But they need to instantiate the
model programmatically and pass it to our tool-interface. They don't want
to know anything about ecore instances or other model behaviour things.
|
|
|
Powered by
FUDForum. Page generated in 0.03040 seconds