Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » doSave Implementation in ResourceImpl missing
doSave Implementation in ResourceImpl missing [message #408375] Tue, 10 April 2007 08:09 Go to next message
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 #408376 is a reply to message #408375] Tue, 10 April 2007 08:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Holger,

Have you tried "Generate Test Code" and looked at the generated
XyzExample.java? That example should just work. A model generated
from an XML Schema should still have a generated resource factory impl
that creates a generated resource impl which extends XMLResourceImpl
which has a doSave method, so I think you must be overlooking something...


Holger Breuer wrote:
> 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 08:35 Go to previous messageGo to next message
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 08:52 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
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
>
>
Re: doSave Implementation in ResourceImpl missing [message #408385 is a reply to message #408380] Tue, 10 April 2007 10:46 Go to previous messageGo to next message
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 #408387 is a reply to message #408385] Tue, 10 April 2007 11:00 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Holger,

I'm confused by these problems. The existing XMLResourceImpl is
functionally complete and should work out of the box. String conversion
methods are created no matter what pattern you use. The data converters
pattern simply makes a one-argument version of them public in the
factory API but that's only so that the generated parser code can call
them most efficiently. EcoreUtil.createFromString/convertToString
should work regardless of what pattern is used. Most likely exceptions
during load are caused by actual syntax errors in the XML being loaded.
What does the stack trace for such an exception look like?


Holger Breuer wrote:
> 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 04:06 Go to previous messageGo to next message
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 08:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
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
>
Re: doSave Implementation in ResourceImpl missing [message #408420 is a reply to message #408411] Wed, 11 April 2007 10:01 Go to previous message
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.
Previous Topic:Allowing "default" Object types
Next Topic:Properties view: changing the "property" and "value" strings
Goto Forum:
  


Current Time: Thu Aug 21 18:19:40 EDT 2014

Powered by FUDForum. Page generated in 0.04677 seconds