Home » Modeling » EMF » Dynamic EMF examples
| |
| Re: Dynamic EMF examples [message #425618 is a reply to message #425613] |
Wed, 03 December 2008 13:20   |
 Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
I am not sure if the xmi document generated by "create dynamic instance"
can help me.
My application involves wrapping an existing java library by EMF (the
old topic we have discussed over the past 2 years). Since EMF is not
reverse-engineering-aware, here is the approach I decided to work on:
(1) The classes in the existing library are extracted using java
reflection and given to the user in the GUI.
(2) Once the user chooses a class to create an object from, an EMF
meta-model is created dynamically, wrapping the existing code. Since the
code is well defined, eg it comes with Set/Get methods, the attributes
can be generated programmatically at run time.
(3) I assume that this result is equivalent of having the static model
and the corresponding generated code and the user should be able to
create instances of the model in an ecore editor.
Does this approach make sense? Are there any examples describing a
similar problem?
Ed Merks wrote:
> Ali,
>
> Many of the JUnit tests use dynamic models, but there's really nothing
> tricky beyond what's in those articles. Even in the Sample Ecore
> Editor, you can right click on an EClass and invoke "Create Dynamic
> Instance..." to see dynamic EMF in action, so that's definitely an
> example...
>
>
> Ali wrote:
>> Ed,
>>
>> Are there any examples on dynamic EMF in the repository? Apart from a
>> couple of articles, by you and your colleagues, back to a few years
>> ago I was not able to find any more resources on dynamic EMF. Perhaps
>> an up to date example can demonstrate new dynamic features.
>>
>>
>> -Ali
|
|
|
| Re: Dynamic EMF examples [message #425620 is a reply to message #425618] |
Wed, 03 December 2008 13:38 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Just to add, here is our last conversation on this:
http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 1748.html
It seems you suggested the use of DynamicEObjectImpl, does this method
still require the creation of a meta-model? Again, any examples around
demonstrating the use of DynamicEObjectImpl?
Ali wrote:
> Ed,
>
> I am not sure if the xmi document generated by "create dynamic instance"
> can help me.
>
> My application involves wrapping an existing java library by EMF (the
> old topic we have discussed over the past 2 years). Since EMF is not
> reverse-engineering-aware, here is the approach I decided to work on:
>
> (1) The classes in the existing library are extracted using java
> reflection and given to the user in the GUI.
>
> (2) Once the user chooses a class to create an object from, an EMF
> meta-model is created dynamically, wrapping the existing code. Since the
> code is well defined, eg it comes with Set/Get methods, the attributes
> can be generated programmatically at run time.
>
> (3) I assume that this result is equivalent of having the static model
> and the corresponding generated code and the user should be able to
> create instances of the model in an ecore editor.
>
> Does this approach make sense? Are there any examples describing a
> similar problem?
>
> Ed Merks wrote:
>> Ali,
>>
>> Many of the JUnit tests use dynamic models, but there's really nothing
>> tricky beyond what's in those articles. Even in the Sample Ecore
>> Editor, you can right click on an EClass and invoke "Create Dynamic
>> Instance..." to see dynamic EMF in action, so that's definitely an
>> example...
>>
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Are there any examples on dynamic EMF in the repository? Apart from a
>>> couple of articles, by you and your colleagues, back to a few years
>>> ago I was not able to find any more resources on dynamic EMF. Perhaps
>>> an up to date example can demonstrate new dynamic features.
>>>
>>>
>>> -Ali
|
|
|
| Re: Dynamic EMF examples [message #425625 is a reply to message #425618] |
Wed, 03 December 2008 13:57 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali wrote:
> Ed,
>
> I am not sure if the xmi document generated by "create dynamic
> instance" can help me.
You're just asking for examples, so that's an example. Given you've
seen several examples now, it's not clear what exactly more you'd need
to see. I think you should just start writing some code and seeing how
it works out.
>
> My application involves wrapping an existing java library by EMF (the
> old topic we have discussed over the past 2 years). Since EMF is not
> reverse-engineering-aware, here is the approach I decided to work on:
>
> (1) The classes in the existing library are extracted using java
> reflection and given to the user in the GUI.
>
> (2) Once the user chooses a class to create an object from, an EMF
> meta-model is created dynamically, wrapping the existing code. Since
> the code is well defined, eg it comes with Set/Get methods, the
> attributes can be generated programmatically at run time.
>
> (3) I assume that this result is equivalent of having the static model
> and the corresponding generated code and the user should be able to
> create instances of the model in an ecore editor.
Well, it seems trickier to try to do it dynamically. At least with
generated code, you could write the methods to delegate data access onto
some other object. You'll certainly need some type of specialized
EDynamicEObjectImpl that delegates using reflection into some other Java
object. You won't find any examples of that...
>
> Does this approach make sense? Are there any examples describing a
> similar problem?
Given all the cool stuff CDO is doing, another approach I can imagine is
treating your legacy object's you're trying to wrap as kind of a
repository or backing store.
>
> Ed Merks wrote:
>> Ali,
>>
>> Many of the JUnit tests use dynamic models, but there's really
>> nothing tricky beyond what's in those articles. Even in the Sample
>> Ecore Editor, you can right click on an EClass and invoke "Create
>> Dynamic Instance..." to see dynamic EMF in action, so that's
>> definitely an example...
>>
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Are there any examples on dynamic EMF in the repository? Apart from
>>> a couple of articles, by you and your colleagues, back to a few
>>> years ago I was not able to find any more resources on dynamic EMF.
>>> Perhaps an up to date example can demonstrate new dynamic features.
>>>
>>>
>>> -Ali
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF examples [message #425630 is a reply to message #425625] |
Wed, 03 December 2008 14:28 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Merks wrote:
> Ali,
>
> Comments below.
>
> Ali wrote:
>> Ed,
>>
>> I am not sure if the xmi document generated by "create dynamic
>> instance" can help me.
> You're just asking for examples, so that's an example. Given you've
> seen several examples now, it's not clear what exactly more you'd need
> to see. I think you should just start writing some code and seeing how
> it works out.
>>
>> My application involves wrapping an existing java library by EMF (the
>> old topic we have discussed over the past 2 years). Since EMF is not
>> reverse-engineering-aware, here is the approach I decided to work on:
>>
>> (1) The classes in the existing library are extracted using java
>> reflection and given to the user in the GUI.
>>
>> (2) Once the user chooses a class to create an object from, an EMF
>> meta-model is created dynamically, wrapping the existing code. Since
>> the code is well defined, eg it comes with Set/Get methods, the
>> attributes can be generated programmatically at run time.
>>
>> (3) I assume that this result is equivalent of having the static model
>> and the corresponding generated code and the user should be able to
>> create instances of the model in an ecore editor.
> Well, it seems trickier to try to do it dynamically. At least with
> generated code, you could write the methods to delegate data access onto
> some other object.
What do you mean by 'writing methods'? The wrapping process is supposed
to be automated.
> You'll certainly need some type of specialized
> EDynamicEObjectImpl that delegates using reflection into some other Java
> object. You won't find any examples of that...
>>
>> Does this approach make sense? Are there any examples describing a
>> similar problem?
> Given all the cool stuff CDO is doing, another approach I can imagine is
> treating your legacy object's you're trying to wrap as kind of a
> repository or backing store.
Does this mean that CDO can act as a wrapper in this way?
May I also ask, why is that EMF, with all its rich features, is not able
to perform simple name conventions for existing code as JavaBean does?
Simple get/set accessor methods in a java class are enough to make java
beans which are ready to be visually edited by a property view which, in
my view, is equivalent of EMF/GMF. Is performing this simple task really
this complicated in EMF or am I missing a point? This is the reason I am
asking for examples before investing time on coding based on the wrong
design.
>>
>> Ed Merks wrote:
>>> Ali,
>>>
>>> Many of the JUnit tests use dynamic models, but there's really
>>> nothing tricky beyond what's in those articles. Even in the Sample
>>> Ecore Editor, you can right click on an EClass and invoke "Create
>>> Dynamic Instance..." to see dynamic EMF in action, so that's
>>> definitely an example...
>>>
>>>
>>> Ali wrote:
>>>> Ed,
>>>>
>>>> Are there any examples on dynamic EMF in the repository? Apart from
>>>> a couple of articles, by you and your colleagues, back to a few
>>>> years ago I was not able to find any more resources on dynamic EMF.
>>>> Perhaps an up to date example can demonstrate new dynamic features.
>>>>
>>>>
>>>> -Ali
|
|
|
| Re: Dynamic EMF examples [message #425634 is a reply to message #425630] |
Wed, 03 December 2008 14:44 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali wrote:
> Ed,
>
> Comments below.
>
>
> Ed Merks wrote:
>> Ali,
>>
>> Comments below.
>>
>> Ali wrote:
>>> Ed,
>>>
>>> I am not sure if the xmi document generated by "create dynamic
>>> instance" can help me.
>> You're just asking for examples, so that's an example. Given you've
>> seen several examples now, it's not clear what exactly more you'd
>> need to see. I think you should just start writing some code and
>> seeing how it works out.
>>>
>>> My application involves wrapping an existing java library by EMF
>>> (the old topic we have discussed over the past 2 years). Since EMF
>>> is not reverse-engineering-aware, here is the approach I decided to
>>> work on:
>>>
>>> (1) The classes in the existing library are extracted using java
>>> reflection and given to the user in the GUI.
>>>
>>> (2) Once the user chooses a class to create an object from, an EMF
>>> meta-model is created dynamically, wrapping the existing code. Since
>>> the code is well defined, eg it comes with Set/Get methods, the
>>> attributes can be generated programmatically at run time.
>>>
>>> (3) I assume that this result is equivalent of having the static
>>> model and the corresponding generated code and the user should be
>>> able to create instances of the model in an ecore editor.
>> Well, it seems trickier to try to do it dynamically. At least with
>> generated code, you could write the methods to delegate data access
>> onto some other object.
>
> What do you mean by 'writing methods'? The wrapping process is
> supposed to be automated.
That would be nice yes, but I could also imagine doing it as a
development time thing up front rather than a runtime time thing on the fly.
>
>
>> You'll certainly need some type of specialized EDynamicEObjectImpl
>> that delegates using reflection into some other Java object. You
>> won't find any examples of that...
>>>
>>> Does this approach make sense? Are there any examples describing a
>>> similar problem?
>> Given all the cool stuff CDO is doing, another approach I can imagine
>> is treating your legacy object's you're trying to wrap as kind of a
>> repository or backing store.
>
> Does this mean that CDO can act as a wrapper in this way?
Yes. CDO EObject act as a facade that communicate with a server to
access data. In general EStoreEObjectImpl can be used in that way to
delegate all data access onto an InternalEObject.EStore. I hesitate to
point this out because you're likely to ask for all kinds of examples
that don't exist.
>
> May I also ask, why is that EMF, with all its rich features, is not
> able to perform simple name conventions for existing code as JavaBean
> does?
We can produce a model from annotated Java, but Java doesn't generally
have enough information. Before Java 5.0, you couldn't even know what
type of object a list contained.
> Simple get/set accessor methods in a java class are enough to make
> java beans which are ready to be visually edited by a property view
> which, in my view, is equivalent of EMF/GMF.
Sure, simple features in an EClass serve the same purpose.
> Is performing this simple task really this complicated in EMF or am I
> missing a point?
How would you use Java Beans to wrap some existing hand-written
classes? That would be just as much work and there's no solution for
that either, right?
> This is the reason I am asking for examples before investing time on
> coding based on the wrong design.
It's not so clear what you're trying to get from EMF. If you already
have beans and are happy with them, then you don't really need EMF.
Sure you can wrap existing classes with EMF, but if anything interacts
directly with the existing classes, the wrappers won't know about that
and won't produce notification. No one has ever worked on producing
such wrappers and contributed that work to open source, so that's why
you don't see it here.
>
>
>>>
>>> Ed Merks wrote:
>>>> Ali,
>>>>
>>>> Many of the JUnit tests use dynamic models, but there's really
>>>> nothing tricky beyond what's in those articles. Even in the Sample
>>>> Ecore Editor, you can right click on an EClass and invoke "Create
>>>> Dynamic Instance..." to see dynamic EMF in action, so that's
>>>> definitely an example...
>>>>
>>>>
>>>> Ali wrote:
>>>>> Ed,
>>>>>
>>>>> Are there any examples on dynamic EMF in the repository? Apart
>>>>> from a couple of articles, by you and your colleagues, back to a
>>>>> few years ago I was not able to find any more resources on dynamic
>>>>> EMF. Perhaps an up to date example can demonstrate new dynamic
>>>>> features.
>>>>>
>>>>>
>>>>> -Ali
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF examples [message #425636 is a reply to message #425634] |
Wed, 03 December 2008 15:08 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Merks wrote:
> Ali,
>
> Comments below.
>
> Ali wrote:
>> Ed,
>>
>> Comments below.
>>
>>
>> Ed Merks wrote:
>>> Ali,
>>>
>>> Comments below.
>>>
>>> Ali wrote:
>>>> Ed,
>>>>
>>>> I am not sure if the xmi document generated by "create dynamic
>>>> instance" can help me.
>>> You're just asking for examples, so that's an example. Given you've
>>> seen several examples now, it's not clear what exactly more you'd
>>> need to see. I think you should just start writing some code and
>>> seeing how it works out.
>>>>
>>>> My application involves wrapping an existing java library by EMF
>>>> (the old topic we have discussed over the past 2 years). Since EMF
>>>> is not reverse-engineering-aware, here is the approach I decided to
>>>> work on:
>>>>
>>>> (1) The classes in the existing library are extracted using java
>>>> reflection and given to the user in the GUI.
>>>>
>>>> (2) Once the user chooses a class to create an object from, an EMF
>>>> meta-model is created dynamically, wrapping the existing code. Since
>>>> the code is well defined, eg it comes with Set/Get methods, the
>>>> attributes can be generated programmatically at run time.
>>>>
>>>> (3) I assume that this result is equivalent of having the static
>>>> model and the corresponding generated code and the user should be
>>>> able to create instances of the model in an ecore editor.
>>> Well, it seems trickier to try to do it dynamically. At least with
>>> generated code, you could write the methods to delegate data access
>>> onto some other object.
>>
>> What do you mean by 'writing methods'? The wrapping process is
>> supposed to be automated.
> That would be nice yes, but I could also imagine doing it as a
> development time thing up front rather than a runtime time thing on the
> fly.
>>
>>
>>> You'll certainly need some type of specialized EDynamicEObjectImpl
>>> that delegates using reflection into some other Java object. You
>>> won't find any examples of that...
>>>>
>>>> Does this approach make sense? Are there any examples describing a
>>>> similar problem?
>>> Given all the cool stuff CDO is doing, another approach I can imagine
>>> is treating your legacy object's you're trying to wrap as kind of a
>>> repository or backing store.
>>
>> Does this mean that CDO can act as a wrapper in this way?
> Yes. CDO EObject act as a facade that communicate with a server to
> access data. In general EStoreEObjectImpl can be used in that way to
> delegate all data access onto an InternalEObject.EStore. I hesitate to
> point this out because you're likely to ask for all kinds of examples
> that don't exist.
Thanks for pointing this out, I'll have a look at this and surely will
get back to you to ask about examples :)
>>
>> May I also ask, why is that EMF, with all its rich features, is not
>> able to perform simple name conventions for existing code as JavaBean
>> does?
> We can produce a model from annotated Java, but Java doesn't generally
> have enough information. Before Java 5.0, you couldn't even know what
> type of object a list contained.
>> Simple get/set accessor methods in a java class are enough to make
>> java beans which are ready to be visually edited by a property view
>> which, in my view, is equivalent of EMF/GMF.
> Sure, simple features in an EClass serve the same purpose.
>> Is performing this simple task really this complicated in EMF or am I
>> missing a point?
> How would you use Java Beans to wrap some existing hand-written
> classes? That would be just as much work and there's no solution for
> that either, right?
Wrong, all we have to do to create Beans is to follow the name
convention, the existing java code is actually generated by SWIG to wrap
c++ objects. So, it is simple to automatically generate the naming
convention and have the Beans *without* any code generation:
[c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
I can also generate java annotations using SWIG to be used by EMF to
generate static models:
[c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
[generated static code] -> [visual editor]
I guess we both agree that automatic generation of annotated java is not
as simple as following accessor naming convention. I was hoping the
dynamic approach to be a work around for this longer process:
[c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
, but, as you wrote, it is trickier. So, back to square one.
>> This is the reason I am asking for examples before investing time on
>> coding based on the wrong design.
> It's not so clear what you're trying to get from EMF. If you already
> have beans and are happy with them, then you don't really need EMF.
Needless to say, I am trying to use EMF as a gate to automatically
import the objects to the eclipse platform. As far as I know there is no
support for Beans in eclipse and, conversely, there is no equivalent of
eclipse for Beans.
> Sure you can wrap existing classes with EMF, but if anything interacts
> directly with the existing classes, the wrappers won't know about that
> and won't produce notification. No one has ever worked on producing
> such wrappers and contributed that work to open source, so that's why
> you don't see it here.
>>
>>
>>>>
>>>> Ed Merks wrote:
>>>>> Ali,
>>>>>
>>>>> Many of the JUnit tests use dynamic models, but there's really
>>>>> nothing tricky beyond what's in those articles. Even in the Sample
>>>>> Ecore Editor, you can right click on an EClass and invoke "Create
>>>>> Dynamic Instance..." to see dynamic EMF in action, so that's
>>>>> definitely an example...
>>>>>
>>>>>
>>>>> Ali wrote:
>>>>>> Ed,
>>>>>>
>>>>>> Are there any examples on dynamic EMF in the repository? Apart
>>>>>> from a couple of articles, by you and your colleagues, back to a
>>>>>> few years ago I was not able to find any more resources on dynamic
>>>>>> EMF. Perhaps an up to date example can demonstrate new dynamic
>>>>>> features.
>>>>>>
>>>>>>
>>>>>> -Ali
|
|
|
| Re: Dynamic EMF examples [message #425639 is a reply to message #425636] |
Wed, 03 December 2008 15:29 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali wrote:
> Ed,
>
> Comments below.
>
> Ed Merks wrote:
>> Ali,
>>
>> Comments below.
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Comments below.
>>>
>>>
>>> Ed Merks wrote:
>>>> Ali,
>>>>
>>>> Comments below.
>>>>
>>>> Ali wrote:
>>>>> Ed,
>>>>>
>>>>> I am not sure if the xmi document generated by "create dynamic
>>>>> instance" can help me.
>>>> You're just asking for examples, so that's an example. Given
>>>> you've seen several examples now, it's not clear what exactly more
>>>> you'd need to see. I think you should just start writing some code
>>>> and seeing how it works out.
>>>>>
>>>>> My application involves wrapping an existing java library by EMF
>>>>> (the old topic we have discussed over the past 2 years). Since EMF
>>>>> is not reverse-engineering-aware, here is the approach I decided
>>>>> to work on:
>>>>>
>>>>> (1) The classes in the existing library are extracted using java
>>>>> reflection and given to the user in the GUI.
>>>>>
>>>>> (2) Once the user chooses a class to create an object from, an EMF
>>>>> meta-model is created dynamically, wrapping the existing code.
>>>>> Since the code is well defined, eg it comes with Set/Get methods,
>>>>> the attributes can be generated programmatically at run time.
>>>>>
>>>>> (3) I assume that this result is equivalent of having the static
>>>>> model and the corresponding generated code and the user should be
>>>>> able to create instances of the model in an ecore editor.
>>>> Well, it seems trickier to try to do it dynamically. At least with
>>>> generated code, you could write the methods to delegate data access
>>>> onto some other object.
>>>
>>> What do you mean by 'writing methods'? The wrapping process is
>>> supposed to be automated.
>> That would be nice yes, but I could also imagine doing it as a
>> development time thing up front rather than a runtime time thing on
>> the fly.
>>>
>>>
>>>> You'll certainly need some type of specialized EDynamicEObjectImpl
>>>> that delegates using reflection into some other Java object. You
>>>> won't find any examples of that...
>>>>>
>>>>> Does this approach make sense? Are there any examples describing a
>>>>> similar problem?
>>>> Given all the cool stuff CDO is doing, another approach I can
>>>> imagine is treating your legacy object's you're trying to wrap as
>>>> kind of a repository or backing store.
>>>
>>> Does this mean that CDO can act as a wrapper in this way?
>> Yes. CDO EObject act as a facade that communicate with a server to
>> access data. In general EStoreEObjectImpl can be used in that way to
>> delegate all data access onto an InternalEObject.EStore. I hesitate
>> to point this out because you're likely to ask for all kinds of
>> examples that don't exist.
>
> Thanks for pointing this out, I'll have a look at this and surely will
> get back to you to ask about examples :)
>
>>>
>>> May I also ask, why is that EMF, with all its rich features, is not
>>> able to perform simple name conventions for existing code as
>>> JavaBean does?
>> We can produce a model from annotated Java, but Java doesn't
>> generally have enough information. Before Java 5.0, you couldn't
>> even know what type of object a list contained.
>>> Simple get/set accessor methods in a java class are enough to make
>>> java beans which are ready to be visually edited by a property view
>>> which, in my view, is equivalent of EMF/GMF.
>> Sure, simple features in an EClass serve the same purpose.
>>> Is performing this simple task really this complicated in EMF or am
>>> I missing a point?
>> How would you use Java Beans to wrap some existing hand-written
>> classes? That would be just as much work and there's no solution for
>> that either, right?
>
> Wrong, all we have to do to create Beans is to follow the name
> convention, the existing java code is actually generated by SWIG to
> wrap c++ objects. So, it is simple to automatically generate the
> naming convention and have the Beans *without* any code generation:
>
> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
So SWIG could have generated EMF object instead of JavaBeans but doesn't.
>
> I can also generate java annotations using SWIG to be used by EMF to
> generate static models:
>
> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
> [generated static code] -> [visual editor]
>
> I guess we both agree that automatic generation of annotated java is
> not as simple as following accessor naming convention.
It seems you could do SWIG -> Ecore?
> I was hoping the dynamic approach to be a work around for this longer
> process:
>
> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
So that's SWIG to Ecore but I don't know what SWIG is. Given that Java
bean solution is static code generation, it makes me wonder again why
you are taking a dynamic approach...
>
> , but, as you wrote, it is trickier. So, back to square one.
>
>>> This is the reason I am asking for examples before investing time on
>>> coding based on the wrong design.
>> It's not so clear what you're trying to get from EMF. If you already
>> have beans and are happy with them, then you don't really need EMF.
>
> Needless to say, I am trying to use EMF as a gate to automatically
> import the objects to the eclipse platform. As far as I know there is
> no support for Beans in eclipse and, conversely, there is no
> equivalent of eclipse for Beans.
The data binding framework supports beans. But beans don't do much all
on their own.
>
>> Sure you can wrap existing classes with EMF, but if anything
>> interacts directly with the existing classes, the wrappers won't know
>> about that and won't produce notification. No one has ever worked on
>> producing such wrappers and contributed that work to open source, so
>> that's why you don't see it here.
>>>
>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Ali,
>>>>>>
>>>>>> Many of the JUnit tests use dynamic models, but there's really
>>>>>> nothing tricky beyond what's in those articles. Even in the
>>>>>> Sample Ecore Editor, you can right click on an EClass and invoke
>>>>>> "Create Dynamic Instance..." to see dynamic EMF in action, so
>>>>>> that's definitely an example...
>>>>>>
>>>>>>
>>>>>> Ali wrote:
>>>>>>> Ed,
>>>>>>>
>>>>>>> Are there any examples on dynamic EMF in the repository? Apart
>>>>>>> from a couple of articles, by you and your colleagues, back to a
>>>>>>> few years ago I was not able to find any more resources on
>>>>>>> dynamic EMF. Perhaps an up to date example can demonstrate new
>>>>>>> dynamic features.
>>>>>>>
>>>>>>>
>>>>>>> -Ali
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF examples [message #425646 is a reply to message #425639] |
Wed, 03 December 2008 17:15 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Merks wrote:
> Ali,
>
> Comments below.
>
>>> How would you use Java Beans to wrap some existing hand-written
>>> classes? That would be just as much work and there's no solution for
>>> that either, right?
>>
>> Wrong, all we have to do to create Beans is to follow the name
>> convention, the existing java code is actually generated by SWIG to
>> wrap c++ objects. So, it is simple to automatically generate the
>> naming convention and have the Beans *without* any code generation:
>>
>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
> So SWIG could have generated EMF object instead of JavaBeans but doesn't.
SWIG is an automated c/c++ wrapper to many languages including java.
SWIG cannot generate EMF objects directly, unless someone develops an
extension of it to generate ecore xml files *directly*. However, like I
mentioned this a couple of times, JavaBean objects may be generated
*directly* from SWIG by simply following the name conventions. Eg, you
can write a simple SWIG script which maps any c++ public methods
starting with Get/Set to get/set and that should be enough to generate
the accessors for the beans. This is not so straightforward in EMF. One
could write a SWIG script to map any c++ public methods starting with
Get/Set to Get/Set in java with an annotation before the java method to
be used with EMF later. I have tried this approach once and encountered
some unforeseen problems such as EMF crashing when generating code for
10^3 classes.
>>
>> I can also generate java annotations using SWIG to be used by EMF to
>> generate static models:
>>
>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>> [generated static code] -> [visual editor]
>>
>> I guess we both agree that automatic generation of annotated java is
>> not as simple as following accessor naming convention.
> It seems you could do SWIG -> Ecore?
>> I was hoping the dynamic approach to be a work around for this longer
>> process:
>>
>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
> So that's SWIG to Ecore but I don't know what SWIG is. Given that Java
> bean solution is static code generation, it makes me wonder again why
> you are taking a dynamic approach...
The above comment explains one of the reasons why I am trying to
consider the dynamic approach now, as the dynamic approach skips code
generation. In practice, the user would not generate thousands of
objects and only a small sub-sample from the pool of objects will be
used in an EMF document--from this point of view, it makes sense to
generate the model for that small sub-sample at run-time and leave the
rest of the pool. Section 13.6 of the EMF book explains how to create a
dynamic model at run-time as well as instantiating it programmatically.
However, it does not say how it is possible to have the editor to use
the dynamic model. Am I missing a point here?
As you have been developing EMF for years, it could be difficult for you
to feel the fuzziness of implementing the dynamic approach without much
documentation or examples for outsiders. I do appreciate the prompt help
in the newsgroup though.
>
>>
>> , but, as you wrote, it is trickier. So, back to square one.
>>
>>>> This is the reason I am asking for examples before investing time on
>>>> coding based on the wrong design.
>>> It's not so clear what you're trying to get from EMF. If you already
>>> have beans and are happy with them, then you don't really need EMF.
>>
>> Needless to say, I am trying to use EMF as a gate to automatically
>> import the objects to the eclipse platform. As far as I know there is
>> no support for Beans in eclipse and, conversely, there is no
>> equivalent of eclipse for Beans.
> The data binding framework supports beans. But beans don't do much all
> on their own.
|
|
|
| Re: Dynamic EMF examples [message #425648 is a reply to message #425646] |
Wed, 03 December 2008 17:26 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070703050702070902060509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ali,
Comments below.
Ali wrote:
> Ed,
>
> Comments below.
>
> Ed Merks wrote:
>> Ali,
>>
>> Comments below.
>>
>>>> How would you use Java Beans to wrap some existing hand-written
>>>> classes? That would be just as much work and there's no solution
>>>> for that either, right?
>>>
>>> Wrong, all we have to do to create Beans is to follow the name
>>> convention, the existing java code is actually generated by SWIG to
>>> wrap c++ objects. So, it is simple to automatically generate the
>>> naming convention and have the Beans *without* any code generation:
>>>
>>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
>> So SWIG could have generated EMF object instead of JavaBeans but
>> doesn't.
>
> SWIG is an automated c/c++ wrapper to many languages including java.
> SWIG cannot generate EMF objects directly, unless someone develops an
> extension of it to generate ecore xml files *directly*. However, like
> I mentioned this a couple of times, JavaBean objects may be generated
> *directly* from SWIG by simply following the name conventions. Eg, you
> can write a simple SWIG script which maps any c++ public methods
> starting with Get/Set to get/set and that should be enough to generate
> the accessors for the beans. This is not so straightforward in EMF.
It should be just as straight forward, but just doesn't exist yet.
> One could write a SWIG script to map any c++ public methods starting
> with Get/Set to Get/Set in java with an annotation before the java
> method to be used with EMF later. I have tried this approach once and
> encountered some unforeseen problems such as EMF crashing when
> generating code for 10^3 classes.
Crashing?
>
>>>
>>> I can also generate java annotations using SWIG to be used by EMF to
>>> generate static models:
>>>
>>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>>> [generated static code] -> [visual editor]
>>>
>>> I guess we both agree that automatic generation of annotated java is
>>> not as simple as following accessor naming convention.
>> It seems you could do SWIG -> Ecore?
>>> I was hoping the dynamic approach to be a work around for this
>>> longer process:
>>>
>>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
>> So that's SWIG to Ecore but I don't know what SWIG is. Given that
>> Java bean solution is static code generation, it makes me wonder
>> again why you are taking a dynamic approach...
>
> The above comment explains one of the reasons why I am trying to
> consider the dynamic approach now, as the dynamic approach skips code
> generation. In practice, the user would not generate thousands of
> objects and only a small sub-sample from the pool of objects will be
> used in an EMF document--from this point of view, it makes sense to
> generate the model for that small sub-sample at run-time and leave the
> rest of the pool. Section 13.6 of the EMF book explains how to create
> a dynamic model at run-time as well as instantiating it
> programmatically. However, it does not say how it is possible to have
> the editor to use the dynamic model. Am I missing a point here?
The reflective editor uses a dynamic model.
>
> As you have been developing EMF for years, it could be difficult for
> you to feel the fuzziness of implementing the dynamic approach without
> much documentation or examples for outsiders.
Yes, it's hard to keep track of what's obvious and what's totally not.
> I do appreciate the prompt help in the newsgroup though.
Probably it would be good to start to dive in and ask more specific
focused questions. For example, I'm sure you will need to create your
own derived EObject implementation and hence you'll end up wanting a
derived EFactoryImpl that overrides this method:
protected EObject basicCreate(EClass eClass)
{
return
eClass.getInstanceClassName() == "java.util.Map$Entry" ?
new DynamicEObjectImpl.BasicEMapEntry<String, String>(eClass) :
new DynamicEObjectImpl(eClass);
}
And you'll want to set this into your EPackage. I would focus first on
getting your scenario working in a simple non-GUI scenario and build up
from there...
>
>>
>>>
>>> , but, as you wrote, it is trickier. So, back to square one.
>>>
>>>>> This is the reason I am asking for examples before investing time
>>>>> on coding based on the wrong design.
>>>> It's not so clear what you're trying to get from EMF. If you
>>>> already have beans and are happy with them, then you don't really
>>>> need EMF.
>>>
>>> Needless to say, I am trying to use EMF as a gate to automatically
>>> import the objects to the eclipse platform. As far as I know there
>>> is no support for Beans in eclipse and, conversely, there is no
>>> equivalent of eclipse for Beans.
>> The data binding framework supports beans. But beans don't do much
>> all on their own.
>
--------------070703050702070902060509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ali,<br>
<br>
Comments below.<br>
<br>
<br>
Ali wrote:
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite">Ed,
<br>
<br>
Comments below.
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Ali,
<br>
<br>
Comments below.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">How would you use Java Beans to wrap some
existing hand-written classes? That would be just as much work and
there's no solution for that either, right?
<br>
</blockquote>
<br>
Wrong, all we have to do to create Beans is to follow the name
convention, the existing java code is actually generated by SWIG to
wrap c++ objects. So, it is simple to automatically generate the naming
convention and have the Beans *without* any code generation:
<br>
<br>
[c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
<br>
</blockquote>
So SWIG could have generated EMF object instead of JavaBeans but
doesn't.
<br>
</blockquote>
<br>
SWIG is an automated c/c++ wrapper to many languages including java.
SWIG cannot generate EMF objects directly, unless someone develops an
extension of it to generate ecore xml files *directly*. However, like I
mentioned this a couple of times, JavaBean objects may be generated
*directly* from SWIG by simply following the name conventions. Eg, you
can write a simple SWIG script which maps any c++ public methods
starting with Get/Set to get/set and that should be enough to generate
the accessors for the beans. This is not so straightforward in EMF.</blockquote>
It should be just as straight forward, but just doesn't exist yet.<br>
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite"> One
could write a SWIG script to map any c++ public methods starting with
Get/Set to Get/Set in java with an annotation before the java method to
be used with EMF later. I have tried this approach once and encountered
some unforeseen problems such as EMF crashing when generating code for
10^3 classes.
<br>
</blockquote>
Crashing?<br>
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite">
<blockquote type="cite"><br>
I can also generate java annotations using SWIG to be used by EMF to
generate static models:
<br>
<br>
[c++] -> [SWIG] -> [annotated java] -> [ecore] ->
[genmodel] -> [generated static code] -> [visual editor]
<br>
<br>
I guess we both agree that automatic generation of annotated java is
not as simple as following accessor naming convention. </blockquote>
It seems you could do SWIG -> Ecore?
<br>
<blockquote type="cite">I was hoping the dynamic approach to be a
work around for this longer process:
<br>
<br>
[c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
<br>
</blockquote>
So that's SWIG to Ecore but I don't know what SWIG is. Given that Java
bean solution is static code generation, it makes me wonder again why
you are taking a dynamic approach...
<br>
</blockquote>
<br>
The above comment explains one of the reasons why I am trying to
consider the dynamic approach now, as the dynamic approach skips code
generation. In practice, the user would not generate thousands of
objects and only a small sub-sample from the pool of objects will be
used in an EMF document--from this point of view, it makes sense to
generate the model for that small sub-sample at run-time and leave the
rest of the pool. Section 13.6 of the EMF book explains how to create a
dynamic model at run-time as well as instantiating it programmatically.
However, it does not say how it is possible to have the editor to use
the dynamic model. Am I missing a point here?
<br>
</blockquote>
The reflective editor uses a dynamic model. <br>
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite"><br>
As you have been developing EMF for years, it could be difficult for
you to feel the fuzziness of implementing the dynamic approach without
much documentation or examples for outsiders.</blockquote>
Yes, it's hard to keep track of what's obvious and what's totally not.<br>
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite"> I do
appreciate the prompt help in the newsgroup though.
<br>
</blockquote>
Probably it would be good to start to dive in and ask more specific
focused questions. For example, I'm sure you will need to create your
own derived EObject implementation and hence you'll end up wanting a
derived EFactoryImpl that overrides this method:<small><br>
</small>
<blockquote><small> protected EObject basicCreate(EClass eClass) </small><br>
<small> {</small><br>
<small> return</small><br>
<small> eClass.getInstanceClassName() == "java.util.Map$Entry" ?</small><br>
<small> new DynamicEObjectImpl.BasicEMapEntry<String,
String>(eClass) :</small><br>
<small> new DynamicEObjectImpl(eClass);</small><br>
<small> }</small><br>
</blockquote>
And you'll want to set this into your EPackage. I would focus first on
getting your scenario working in a simple non-GUI scenario and build up
from there...<br>
<blockquote cite="mid:gh6er1$4rl$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite"><br>
<blockquote type="cite"><br>
, but, as you wrote, it is trickier. So, back to square one.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">This is the reason I am asking for
examples before investing time on coding based on the wrong design.
<br>
</blockquote>
It's not so clear what you're trying to get from EMF. If you already
have beans and are happy with them, then you don't really need EMF.
<br>
</blockquote>
<br>
Needless to say, I am trying to use EMF as a gate to automatically
import the objects to the eclipse platform. As far as I know there is
no support for Beans in eclipse and, conversely, there is no equivalent
of eclipse for Beans.
<br>
</blockquote>
The data binding framework supports beans. But beans don't do much all
on their own.
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------070703050702070902060509--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF examples [message #425655 is a reply to message #425648] |
Wed, 03 December 2008 21:02 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Thanks for making some points clear. Following your advice, here is a
minimal simplified problem:
Let's consider a simple thin wrapper java class as the existing code:
public class WrapperClass {
public void SetSomething(int value) {
// Some call to JNI
}
public int GetSomething() {
// Some call to JNI
}
}
For now, we ignore how this class and its package can be automatically
looked up and provided to the user. Given the above class, all we want
is to:
(1) Automatically detect the attributes and their types by simply
matching SetX/GetX. Even this part is not EMF-related and may be ignored.
(2) Based on the class name and its attributes names and types, create a
dynamic model where the user can instantiate the class in a reflective
editor.
Your suggestion involves starting from sub-classing EObject. How can
this fit into the above? Does DynamicSet/DynamicGet have any use in this?
I hope the question is concrete and focused enough now. If this can be
answered, I will have a base to continue.
Ed Merks wrote:
> Ali,
>
> Comments below.
>
>
> Ali wrote:
>> Ed,
>>
>> Comments below.
>>
>> Ed Merks wrote:
>>> Ali,
>>>
>>> Comments below.
>>>
>>>>> How would you use Java Beans to wrap some existing hand-written
>>>>> classes? That would be just as much work and there's no solution
>>>>> for that either, right?
>>>>
>>>> Wrong, all we have to do to create Beans is to follow the name
>>>> convention, the existing java code is actually generated by SWIG to
>>>> wrap c++ objects. So, it is simple to automatically generate the
>>>> naming convention and have the Beans *without* any code generation:
>>>>
>>>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
>>> So SWIG could have generated EMF object instead of JavaBeans but
>>> doesn't.
>>
>> SWIG is an automated c/c++ wrapper to many languages including java.
>> SWIG cannot generate EMF objects directly, unless someone develops an
>> extension of it to generate ecore xml files *directly*. However, like
>> I mentioned this a couple of times, JavaBean objects may be generated
>> *directly* from SWIG by simply following the name conventions. Eg, you
>> can write a simple SWIG script which maps any c++ public methods
>> starting with Get/Set to get/set and that should be enough to generate
>> the accessors for the beans. This is not so straightforward in EMF.
> It should be just as straight forward, but just doesn't exist yet.
>> One could write a SWIG script to map any c++ public methods starting
>> with Get/Set to Get/Set in java with an annotation before the java
>> method to be used with EMF later. I have tried this approach once and
>> encountered some unforeseen problems such as EMF crashing when
>> generating code for 10^3 classes.
> Crashing?
>>
>>>>
>>>> I can also generate java annotations using SWIG to be used by EMF to
>>>> generate static models:
>>>>
>>>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>>>> [generated static code] -> [visual editor]
>>>>
>>>> I guess we both agree that automatic generation of annotated java is
>>>> not as simple as following accessor naming convention.
>>> It seems you could do SWIG -> Ecore?
>>>> I was hoping the dynamic approach to be a work around for this
>>>> longer process:
>>>>
>>>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
>>> So that's SWIG to Ecore but I don't know what SWIG is. Given that
>>> Java bean solution is static code generation, it makes me wonder
>>> again why you are taking a dynamic approach...
>>
>> The above comment explains one of the reasons why I am trying to
>> consider the dynamic approach now, as the dynamic approach skips code
>> generation. In practice, the user would not generate thousands of
>> objects and only a small sub-sample from the pool of objects will be
>> used in an EMF document--from this point of view, it makes sense to
>> generate the model for that small sub-sample at run-time and leave the
>> rest of the pool. Section 13.6 of the EMF book explains how to create
>> a dynamic model at run-time as well as instantiating it
>> programmatically. However, it does not say how it is possible to have
>> the editor to use the dynamic model. Am I missing a point here?
> The reflective editor uses a dynamic model.
>>
>> As you have been developing EMF for years, it could be difficult for
>> you to feel the fuzziness of implementing the dynamic approach without
>> much documentation or examples for outsiders.
> Yes, it's hard to keep track of what's obvious and what's totally not.
>> I do appreciate the prompt help in the newsgroup though.
> Probably it would be good to start to dive in and ask more specific
> focused questions. For example, I'm sure you will need to create your
> own derived EObject implementation and hence you'll end up wanting a
> derived EFactoryImpl that overrides this method:
>
> protected EObject basicCreate(EClass eClass)
> {
> return
> eClass.getInstanceClassName() == "java.util.Map$Entry" ?
> new DynamicEObjectImpl.BasicEMapEntry<String, String>(eClass) :
> new DynamicEObjectImpl(eClass);
> }
>
> And you'll want to set this into your EPackage. I would focus first on
> getting your scenario working in a simple non-GUI scenario and build up
> from there...
>>
>>>
>>>>
>>>> , but, as you wrote, it is trickier. So, back to square one.
>>>>
>>>>>> This is the reason I am asking for examples before investing time
>>>>>> on coding based on the wrong design.
>>>>> It's not so clear what you're trying to get from EMF. If you
>>>>> already have beans and are happy with them, then you don't really
>>>>> need EMF.
>>>>
>>>> Needless to say, I am trying to use EMF as a gate to automatically
>>>> import the objects to the eclipse platform. As far as I know there
>>>> is no support for Beans in eclipse and, conversely, there is no
>>>> equivalent of eclipse for Beans.
>>> The data binding framework supports beans. But beans don't do much
>>> all on their own.
>>
|
|
|
| Re: Dynamic EMF examples [message #425657 is a reply to message #425655] |
Wed, 03 December 2008 21:53 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali wrote:
> Ed,
>
> Thanks for making some points clear.
Sorry that I've been slightly less than my diplomatic best...
> Following your advice, here is a minimal simplified problem:
>
> Let's consider a simple thin wrapper java class as the existing code:
>
> public class WrapperClass {
> public void SetSomething(int value) {
> // Some call to JNI
> }
> public int GetSomething() {
> // Some call to JNI
> }
> }
>
> For now, we ignore how this class and its package can be automatically
> looked up and provided to the user. Given the above class, all we want
> is to:
>
> (1) Automatically detect the attributes and their types by simply
> matching SetX/GetX. Even this part is not EMF-related and may be ignored.
Probably you mean setX and getX, right?
>
> (2) Based on the class name and its attributes names and types, create
> a dynamic model where the user can instantiate the class in a
> reflective editor.
Yes, I could certainly imagine using Java reflection to gather such
information directly from the instance.
>
> Your suggestion involves starting from sub-classing EObject. How can
> this fit into the above? Does DynamicSet/DynamicGet have any use in this?
From what I understand, I think the following is a good start. I
imagine when you create objects you'll need to decide how to make them
wrap something and you'll need to make the reflectively method do the
JNI thing...
package org.example;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EAttribute;
import org.eclipse.emf.ecore.EClass;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.EPackage;
import org.eclipse.emf.ecore.EcoreFactory;
import org.eclipse.emf.ecore.EcorePackage;
import org.eclipse.emf.ecore.impl.DynamicEObjectImpl;
import org.eclipse.emf.ecore.impl.EFactoryImpl;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
import org.eclipse.emf.ecore.util.Diagnostician;
import org.eclipse.emf.ecore.xmi.impl.XMLResourceFactoryImpl;
public class Dynamic
{
interface Wrapper extends EObject
{
void setWrappedObject(Object object);
}
static class MyDynamicEObjectImpl extends DynamicEObjectImpl
implements Wrapper
{
Object wrappedObject;
public MyDynamicEObjectImpl(EClass eClass)
{
super(eClass);
}
public void setWrappedObject(Object object)
{
wrappedObject = object;
}
@Override
public Object eGet(int featureID, boolean resolve, boolean coreType)
{
System.out.println("how to use JNI to get " +
eClass().getEStructuralFeature(featureID).getName());
return super.eGet(featureID, resolve, coreType);
}
@Override
public void eSet(int featureID, Object newValue)
{
System.out.println("how to use JNI to set " +
eClass().getEStructuralFeature(featureID).getName());
super.eSet(featureID, newValue);
}
}
public static void main(String[] args) throws Exception
{
EPackage ePackage = EcoreFactory.eINSTANCE.createEPackage();
ePackage.setName("dynamic");
ePackage.setNsPrefix("dynamic");
ePackage.setNsURI("http://www.example.org/dynamic");
EClass eClass = EcoreFactory.eINSTANCE.createEClass();
eClass.setName("WrapperClass");
EAttribute eAttribute = EcoreFactory.eINSTANCE.createEAttribute();
eAttribute.setName("something");
eAttribute.setEType(EcorePackage.Literals.EINT);
eClass.getEStructuralFeatures().add(eAttribute);
ePackage.getEClassifiers().add(eClass);
System.out.println(Diagnostician.INSTANCE.validate(ePackage) );
{
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMLResourceFactoryImpl());
Resource resource =
resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
EObject eObject = ePackage.getEFactoryInstance().create(eClass);
eObject.eSet(eAttribute, 10);
resource.getContents().add(eObject);
resource.save(System.out, null);
}
{
ePackage.setEFactoryInstance
(new EFactoryImpl()
{
@Override
protected EObject basicCreate(EClass eClass)
{
return new MyDynamicEObjectImpl(eClass);
}
});
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMLResourceFactoryImpl());
Resource resource =
resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
Wrapper wrapper =
(Wrapper)ePackage.getEFactoryInstance().create(eClass);
wrapper.setWrappedObject(null);
wrapper.eSet(eAttribute, 10);
resource.getContents().add(wrapper);
resource.save(System.out, null);
}
}
}
>
> I hope the question is concrete and focused enough now. If this can be
> answered, I will have a base to continue.
It sounds like an interesting problem. Hopefully you'll share some of
your progress.
>
>
> Ed Merks wrote:
>> Ali,
>>
>> Comments below.
>>
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Comments below.
>>>
>>> Ed Merks wrote:
>>>> Ali,
>>>>
>>>> Comments below.
>>>>
>>>>>> How would you use Java Beans to wrap some existing hand-written
>>>>>> classes? That would be just as much work and there's no solution
>>>>>> for that either, right?
>>>>>
>>>>> Wrong, all we have to do to create Beans is to follow the name
>>>>> convention, the existing java code is actually generated by SWIG
>>>>> to wrap c++ objects. So, it is simple to automatically generate
>>>>> the naming convention and have the Beans *without* any code
>>>>> generation:
>>>>>
>>>>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
>>>> So SWIG could have generated EMF object instead of JavaBeans but
>>>> doesn't.
>>>
>>> SWIG is an automated c/c++ wrapper to many languages including java.
>>> SWIG cannot generate EMF objects directly, unless someone develops
>>> an extension of it to generate ecore xml files *directly*. However,
>>> like I mentioned this a couple of times, JavaBean objects may be
>>> generated *directly* from SWIG by simply following the name
>>> conventions. Eg, you can write a simple SWIG script which maps any
>>> c++ public methods starting with Get/Set to get/set and that should
>>> be enough to generate the accessors for the beans. This is not so
>>> straightforward in EMF.
>> It should be just as straight forward, but just doesn't exist yet.
>>> One could write a SWIG script to map any c++ public methods starting
>>> with Get/Set to Get/Set in java with an annotation before the java
>>> method to be used with EMF later. I have tried this approach once
>>> and encountered some unforeseen problems such as EMF crashing when
>>> generating code for 10^3 classes.
>> Crashing?
>>>
>>>>>
>>>>> I can also generate java annotations using SWIG to be used by EMF
>>>>> to generate static models:
>>>>>
>>>>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>>>>> [generated static code] -> [visual editor]
>>>>>
>>>>> I guess we both agree that automatic generation of annotated java
>>>>> is not as simple as following accessor naming convention.
>>>> It seems you could do SWIG -> Ecore?
>>>>> I was hoping the dynamic approach to be a work around for this
>>>>> longer process:
>>>>>
>>>>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
>>>> So that's SWIG to Ecore but I don't know what SWIG is. Given that
>>>> Java bean solution is static code generation, it makes me wonder
>>>> again why you are taking a dynamic approach...
>>>
>>> The above comment explains one of the reasons why I am trying to
>>> consider the dynamic approach now, as the dynamic approach skips
>>> code generation. In practice, the user would not generate thousands
>>> of objects and only a small sub-sample from the pool of objects will
>>> be used in an EMF document--from this point of view, it makes sense
>>> to generate the model for that small sub-sample at run-time and
>>> leave the rest of the pool. Section 13.6 of the EMF book explains
>>> how to create a dynamic model at run-time as well as instantiating
>>> it programmatically. However, it does not say how it is possible to
>>> have the editor to use the dynamic model. Am I missing a point here?
>> The reflective editor uses a dynamic model.
>>>
>>> As you have been developing EMF for years, it could be difficult for
>>> you to feel the fuzziness of implementing the dynamic approach
>>> without much documentation or examples for outsiders.
>> Yes, it's hard to keep track of what's obvious and what's totally not.
>>> I do appreciate the prompt help in the newsgroup though.
>> Probably it would be good to start to dive in and ask more specific
>> focused questions. For example, I'm sure you will need to create
>> your own derived EObject implementation and hence you'll end up
>> wanting a derived EFactoryImpl that overrides this method:
>>
>> protected EObject basicCreate(EClass eClass)
>> {
>> return
>> eClass.getInstanceClassName() == "java.util.Map$Entry" ?
>> new DynamicEObjectImpl.BasicEMapEntry<String,
>> String>(eClass) :
>> new DynamicEObjectImpl(eClass);
>> }
>>
>> And you'll want to set this into your EPackage. I would focus first
>> on getting your scenario working in a simple non-GUI scenario and
>> build up from there...
>>>
>>>>
>>>>>
>>>>> , but, as you wrote, it is trickier. So, back to square one.
>>>>>
>>>>>>> This is the reason I am asking for examples before investing
>>>>>>> time on coding based on the wrong design.
>>>>>> It's not so clear what you're trying to get from EMF. If you
>>>>>> already have beans and are happy with them, then you don't really
>>>>>> need EMF.
>>>>>
>>>>> Needless to say, I am trying to use EMF as a gate to automatically
>>>>> import the objects to the eclipse platform. As far as I know there
>>>>> is no support for Beans in eclipse and, conversely, there is no
>>>>> equivalent of eclipse for Beans.
>>>> The data binding framework supports beans. But beans don't do much
>>>> all on their own.
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dynamic EMF examples [message #425689 is a reply to message #425657] |
Thu, 04 December 2008 18:21 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000606050300040802090407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
Thanks a lot, that was the 'example' I was looking for. I have started
mapping the JNI wrapping structure to the EMF one, please see attached.
To answer your question about set/get, I did meant Set/Get. To avoid
confusion, I changed it to MySet/MyGet. While we have the control over
the accessor name pattern, it would be good to generalise it in the case
of wrapping a third party code.
With the current design, we are actually double-wrapping:
[EMF] --(wraps)--> [existing JNI wrapper] --(wraps)--> [c++ code]
In long term, it would be a good idea to have a SWIG extension which
generates direct EMF wrapper--I am sure there will be a lot of interest
in this.
Some questions:
(1) The performance sacrifice of the dynamic approach is well known. Let
us consider creating a dynamic model and using EMFWrapperClass to create
20 - 40 objects on the fly.
(1.1) Would the dynamic performance loss be substantial in the case of
this thin wrapper?
(1.2) Let us compare this case to the case of having about 1,000
classes where the EMF wrapper code has been statistically generated for
them. Even with the lazy-loading strategy in the static case, would we
not actually *gain* some performance by the dynamic approach as we wrap
those few classes that we require? This is literally a genuine`
'lazy'-loading scheme.
(2) What would be the right way of setting the default values of the
attributes in EMFWrapperClass automatically? It is desirable to have the
EMF attributes initialised by the default values in the c++ object.
(3) Having the ResourceSet instance, how is it possible to present it in
the EMF editor just like the static case?
Ed Merks wrote:
> Ali,
>
> Comments below.
>
> Ali wrote:
>> Ed,
>>
>> Thanks for making some points clear.
> Sorry that I've been slightly less than my diplomatic best...
>> Following your advice, here is a minimal simplified problem:
>>
>> Let's consider a simple thin wrapper java class as the existing code:
>>
>> public class WrapperClass {
>> public void SetSomething(int value) {
>> // Some call to JNI
>> }
>> public int GetSomething() {
>> // Some call to JNI
>> }
>> }
>>
>> For now, we ignore how this class and its package can be automatically
>> looked up and provided to the user. Given the above class, all we want
>> is to:
>>
>> (1) Automatically detect the attributes and their types by simply
>> matching SetX/GetX. Even this part is not EMF-related and may be ignored.
> Probably you mean setX and getX, right?
>>
>> (2) Based on the class name and its attributes names and types, create
>> a dynamic model where the user can instantiate the class in a
>> reflective editor.
> Yes, I could certainly imagine using Java reflection to gather such
> information directly from the instance.
>>
>> Your suggestion involves starting from sub-classing EObject. How can
>> this fit into the above? Does DynamicSet/DynamicGet have any use in this?
> From what I understand, I think the following is a good start. I
> imagine when you create objects you'll need to decide how to make them
> wrap something and you'll need to make the reflectively method do the
> JNI thing...
>
> package org.example;
>
> import org.eclipse.emf.common.util.URI;
> import org.eclipse.emf.ecore.EAttribute;
> import org.eclipse.emf.ecore.EClass;
> import org.eclipse.emf.ecore.EObject;
> import org.eclipse.emf.ecore.EPackage;
> import org.eclipse.emf.ecore.EcoreFactory;
> import org.eclipse.emf.ecore.EcorePackage;
> import org.eclipse.emf.ecore.impl.DynamicEObjectImpl;
> import org.eclipse.emf.ecore.impl.EFactoryImpl;
> import org.eclipse.emf.ecore.resource.Resource;
> import org.eclipse.emf.ecore.resource.ResourceSet;
> import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
> import org.eclipse.emf.ecore.util.Diagnostician;
> import org.eclipse.emf.ecore.xmi.impl.XMLResourceFactoryImpl;
>
> public class Dynamic
> {
> interface Wrapper extends EObject
> {
> void setWrappedObject(Object object);
> }
>
> static class MyDynamicEObjectImpl extends DynamicEObjectImpl implements
> Wrapper
> {
> Object wrappedObject;
>
> public MyDynamicEObjectImpl(EClass eClass)
> {
> super(eClass);
> }
> public void setWrappedObject(Object object)
> {
> wrappedObject = object;
> }
> @Override
> public Object eGet(int featureID, boolean resolve, boolean coreType)
> {
> System.out.println("how to use JNI to get " +
> eClass().getEStructuralFeature(featureID).getName());
> return super.eGet(featureID, resolve, coreType);
> }
>
> @Override
> public void eSet(int featureID, Object newValue)
> {
> System.out.println("how to use JNI to set " +
> eClass().getEStructuralFeature(featureID).getName());
> super.eSet(featureID, newValue);
> }
> }
>
> public static void main(String[] args) throws Exception
> {
> EPackage ePackage = EcoreFactory.eINSTANCE.createEPackage();
> ePackage.setName("dynamic");
> ePackage.setNsPrefix("dynamic");
> ePackage.setNsURI("http://www.example.org/dynamic");
> EClass eClass = EcoreFactory.eINSTANCE.createEClass();
> eClass.setName("WrapperClass");
> EAttribute eAttribute = EcoreFactory.eINSTANCE.createEAttribute();
> eAttribute.setName("something");
> eAttribute.setEType(EcorePackage.Literals.EINT);
> eClass.getEStructuralFeatures().add(eAttribute);
> ePackage.getEClassifiers().add(eClass);
> System.out.println(Diagnostician.INSTANCE.validate(ePackage) );
> {
> ResourceSet resourceSet = new ResourceSetImpl();
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XMLResourceFactoryImpl());
> Resource resource =
> resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
> EObject eObject = ePackage.getEFactoryInstance().create(eClass);
> eObject.eSet(eAttribute, 10);
> resource.getContents().add(eObject);
> resource.save(System.out, null);
> }
> {
> ePackage.setEFactoryInstance
> (new EFactoryImpl()
> {
> @Override
> protected EObject basicCreate(EClass eClass)
> {
> return new MyDynamicEObjectImpl(eClass);
> }
> });
>
> ResourceSet resourceSet = new ResourceSetImpl();
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XMLResourceFactoryImpl());
> Resource resource =
> resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
> Wrapper wrapper =
> (Wrapper)ePackage.getEFactoryInstance().create(eClass);
> wrapper.setWrappedObject(null);
> wrapper.eSet(eAttribute, 10);
> resource.getContents().add(wrapper);
> resource.save(System.out, null);
> }
> }
> }
>
>
>>
>> I hope the question is concrete and focused enough now. If this can be
>> answered, I will have a base to continue.
> It sounds like an interesting problem. Hopefully you'll share some of
> your progress.
>>
>>
>> Ed Merks wrote:
>>> Ali,
>>>
>>> Comments below.
>>>
>>>
>>> Ali wrote:
>>>> Ed,
>>>>
>>>> Comments below.
>>>>
>>>> Ed Merks wrote:
>>>>> Ali,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>>> How would you use Java Beans to wrap some existing hand-written
>>>>>>> classes? That would be just as much work and there's no solution
>>>>>>> for that either, right?
>>>>>>
>>>>>> Wrong, all we have to do to create Beans is to follow the name
>>>>>> convention, the existing java code is actually generated by SWIG
>>>>>> to wrap c++ objects. So, it is simple to automatically generate
>>>>>> the naming convention and have the Beans *without* any code
>>>>>> generation:
>>>>>>
>>>>>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
>>>>> So SWIG could have generated EMF object instead of JavaBeans but
>>>>> doesn't.
>>>>
>>>> SWIG is an automated c/c++ wrapper to many languages including java.
>>>> SWIG cannot generate EMF objects directly, unless someone develops
>>>> an extension of it to generate ecore xml files *directly*. However,
>>>> like I mentioned this a couple of times, JavaBean objects may be
>>>> generated *directly* from SWIG by simply following the name
>>>> conventions. Eg, you can write a simple SWIG script which maps any
>>>> c++ public methods starting with Get/Set to get/set and that should
>>>> be enough to generate the accessors for the beans. This is not so
>>>> straightforward in EMF.
>>> It should be just as straight forward, but just doesn't exist yet.
>>>> One could write a SWIG script to map any c++ public methods starting
>>>> with Get/Set to Get/Set in java with an annotation before the java
>>>> method to be used with EMF later. I have tried this approach once
>>>> and encountered some unforeseen problems such as EMF crashing when
>>>> generating code for 10^3 classes.
>>> Crashing?
>>>>
>>>>>>
>>>>>> I can also generate java annotations using SWIG to be used by EMF
>>>>>> to generate static models:
>>>>>>
>>>>>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>>>>>> [generated static code] -> [visual editor]
>>>>>>
>>>>>> I guess we both agree that automatic generation of annotated java
>>>>>> is not as simple as following accessor naming convention.
>>>>> It seems you could do SWIG -> Ecore?
>>>>>> I was hoping the dynamic approach to be a work around for this
>>>>>> longer process:
>>>>>>
>>>>>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
>>>>> So that's SWIG to Ecore but I don't know what SWIG is. Given that
>>>>> Java bean solution is static code generation, it makes me wonder
>>>>> again why you are taking a dynamic approach...
>>>>
>>>> The above comment explains one of the reasons why I am trying to
>>>> consider the dynamic approach now, as the dynamic approach skips
>>>> code generation. In practice, the user would not generate thousands
>>>> of objects and only a small sub-sample from the pool of objects will
>>>> be used in an EMF document--from this point of view, it makes sense
>>>> to generate the model for that small sub-sample at run-time and
>>>> leave the rest of the pool. Section 13.6 of the EMF book explains
>>>> how to create a dynamic model at run-time as well as instantiating
>>>> it programmatically. However, it does not say how it is possible to
>>>> have the editor to use the dynamic model. Am I missing a point here?
>>> The reflective editor uses a dynamic model.
>>>>
>>>> As you have been developing EMF for years, it could be difficult for
>>>> you to feel the fuzziness of implementing the dynamic approach
>>>> without much documentation or examples for outsiders.
>>> Yes, it's hard to keep track of what's obvious and what's totally not.
>>>> I do appreciate the prompt help in the newsgroup though.
>>> Probably it would be good to start to dive in and ask more specific
>>> focused questions. For example, I'm sure you will need to create
>>> your own derived EObject implementation and hence you'll end up
>>> wanting a derived EFactoryImpl that overrides this method:
>>>
>>> protected EObject basicCreate(EClass eClass)
>>> {
>>> return
>>> eClass.getInstanceClassName() == "java.util.Map$Entry" ?
>>> new DynamicEObjectImpl.BasicEMapEntry<String,
>>> String>(eClass) :
>>> new DynamicEObjectImpl(eClass);
>>> }
>>>
>>> And you'll want to set this into your EPackage. I would focus first
>>> on getting your scenario working in a simple non-GUI scenario and
>>> build up from there...
>>>>
>>>>>
>>>>>>
>>>>>> , but, as you wrote, it is trickier. So, back to square one.
>>>>>>
>>>>>>>> This is the reason I am asking for examples before investing
>>>>>>>> time on coding based on the wrong design.
>>>>>>> It's not so clear what you're trying to get from EMF. If you
>>>>>>> already have beans and are happy with them, then you don't really
>>>>>>> need EMF.
>>>>>>
>>>>>> Needless to say, I am trying to use EMF as a gate to automatically
>>>>>> import the objects to the eclipse platform. As far as I know there
>>>>>> is no support for Beans in eclipse and, conversely, there is no
>>>>>> equivalent of eclipse for Beans.
>>>>> The data binding framework supports beans. But beans don't do much
>>>>> all on their own.
>>>>
--------------000606050300040802090407
Content-Type: text/plain;
name="EMFWrapperClass.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="EMFWrapperClass.java"
package org.example;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EAttribute;
import org.eclipse.emf.ecore.EClass;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.EPackage;
import org.eclipse.emf.ecore.EcoreFactory;
import org.eclipse.emf.ecore.EcorePackage;
import org.eclipse.emf.ecore.impl.DynamicEObjectImpl;
import org.eclipse.emf.ecore.impl.EFactoryImpl;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
import org.eclipse.emf.ecore.util.Diagnostician;
import org.eclipse.emf.ecore.xmi.impl.XMLResourceFactoryImpl;
import java.lang.reflect.*;
public class EMFWrapperClass {
interface WrapperEObject extends EObject {
void setWrappedObject(Object object);
void setAccessorSetString(String str);
void setAccessorGetString(String str);
}
static class MyDynamicEObjectImpl extends DynamicEObjectImpl implements
WrapperEObject {
Object wrappedObject;
String accessorSetString = "set";
String accessorGetString = "get";
public MyDynamicEObjectImpl(EClass eClass) {
super(eClass);
}
public void setWrappedObject(Object object) {
wrappedObject = object;
}
public void setAccessorSetString(String str) {
accessorSetString = str;
}
public void setAccessorGetString(String str) {
accessorGetString = str;
}
@Override
public Object eGet(int featureID, boolean resolve, boolean coreType) {
String getString = accessorGetString
+ eClass().getEStructuralFeature(featureID).getName();
System.out.println("[EMFWrapperClass] eGet, " + getString);
return super.eGet(featureID, resolve, coreType);
}
@Override
public void eSet(int featureID, Object newValue) {
String setMethodName = accessorSetString
+ eClass().getEStructuralFeature(featureID).getName();
Class attribType = eClass().getEStructuralFeature(featureID).getEType().getInst anceClass();
System.out.println("[EMFWrapperClass] eGet, " + setMethodName + "("
+ attribType.getName() + ")");
// call the jni wrapper method
try {
Method mth = wrappedObject.getClass().getMethod(setMethodName, attribType);
mth.invoke(wrappedObject, newValue);
} catch (Exception e) {
e.printStackTrace();
}
super.eSet(featureID, newValue);
}
}
public static void main(String[] args) throws Exception {
EPackage ePackage = EcoreFactory.eINSTANCE.createEPackage();
ePackage.setName("EMFWrapper");
ePackage.setNsPrefix("EMFWrapper");
ePackage.setNsURI("http://www.example.org/EMFWrapper");
EClass eClass = EcoreFactory.eINSTANCE.createEClass();
eClass.setName("WrapperClass");
EAttribute eAttribute = EcoreFactory.eINSTANCE.createEAttribute();
eAttribute.setName("Something");
eAttribute.setEType(EcorePackage.Literals.EINT);
eClass.getEStructuralFeatures().add(eAttribute);
ePackage.getEClassifiers().add(eClass);
System.out.println(Diagnostician.INSTANCE.validate(ePackage) );
System.out.println("-------");
{
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
.put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMLResourceFactoryImpl());
Resource resource = resourceSet.createResource(URI
.createURI("file:/c:/dynamic.xml"));
EObject eObject = ePackage.getEFactoryInstance().create(eClass);
eObject.eSet(eAttribute, 10);
resource.getContents().add(eObject);
resource.save(System.out, null);
}
System.out.println("-------");
{
ePackage.setEFactoryInstance(new EFactoryImpl() {
@Override
protected EObject basicCreate(EClass eClass) {
return new MyDynamicEObjectImpl(eClass);
}
});
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
.put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMLResourceFactoryImpl());
Resource resource = resourceSet.createResource(URI
.createURI("file:/c:/dynamic.xml"));
WrapperEObject wrapper = (WrapperEObject) ePackage
.getEFactoryInstance().create(eClass);
JNIWrapperClass jniWrapper = new JNIWrapperClass();
wrapper.setWrappedObject(jniWrapper);
wrapper.setAccessorSetString("MySet");
wrapper.setAccessorGetString("MyGet");
wrapper.eSet(eAttribute, 10);
resource.getContents().add(wrapper);
resource.save(System.out, null);
}
System.out.println("-------");
}
}
--------------000606050300040802090407
Content-Type: text/plain;
name="JNIWrapperClass.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="JNIWrapperClass.java"
package org.example;
// JNIWrapperClass is assumed to be the existing code to
// be double-wrapped
public class JNIWrapperClass {
int something = 7;
public void MySetSomething(int value) {
System.out.println("[JNIWrapperClass] MySetSomething, Something = " + something + " -> " + value);
something = value;
}
public int MyGetSomething() {
System.out.println("[JNIWrapperClass] MyGetSomething, Something = " + something);
return something;
}
}
--------------000606050300040802090407--
|
|
|
| Re: Dynamic EMF examples [message #425690 is a reply to message #425689] |
Thu, 04 December 2008 18:46 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali wrote:
> Ed,
>
> Thanks a lot, that was the 'example' I was looking for. I have started
> mapping the JNI wrapping structure to the EMF one, please see attached.
>
> To answer your question about set/get, I did meant Set/Get. To avoid
> confusion, I changed it to MySet/MyGet. While we have the control over
> the accessor name pattern, it would be good to generalise it in the case
> of wrapping a third party code.
>
> With the current design, we are actually double-wrapping:
>
> [EMF] --(wraps)--> [existing JNI wrapper] --(wraps)--> [c++ code]
>
> In long term, it would be a good idea to have a SWIG extension which
> generates direct EMF wrapper--I am sure there will be a lot of interest
> in this.
>
> Some questions:
>
> (1) The performance sacrifice of the dynamic approach is well known.
> Let us consider creating a dynamic model and using EMFWrapperClass to
> create 20 - 40 objects on the fly.
> (1.1) Would the dynamic performance loss be substantial in the
> case of this thin wrapper?
When it comes to performance all I can suggest is measure, measure, and
measure it again. You might find that performance is irrelevant in your
context.
> (1.2) Let us compare this case to the case of having about 1,000
> classes where the EMF wrapper code has been statistically generated
> for them. Even with the lazy-loading strategy in the static case,
> would we not actually *gain* some performance by the dynamic approach
> as we wrap those few classes that we require? This is literally a
> genuine` 'lazy'-loading scheme.
Given that the meta data process is a one-time cost verses processing
each instance which is done n times for n instances, I doubt that the
one time meta data costs will be significant compared to the scaling the
number of instances either way. Far more likely to be a performance
problem is the method lookup each time a feature is looked up for each
instance, i.e., all this is likely to add up and dominate your time (and
of course it's information that can be cached once per EStructuralFeature):
String setMethodName = accessorSetString
+ eClass().getEStructuralFeature(featureID).getName();
Class attribType =
eClass().getEStructuralFeature(featureID).getEType().getInst anceClass();
System.out.println("[EMFWrapperClass] eGet, " +
setMethodName + "("
+ attribType.getName() + ")");
// call the jni wrapper method
try {
Method mth =
wrappedObject.getClass().getMethod(setMethodName, attribType);
>
>
> (2) What would be the right way of setting the default values of the
> attributes in EMFWrapperClass automatically?
The EAttribute itself can have a default, but doesn't the getter always
return the value in the wrapped object hence making default irrelevant?
> It is desirable to have the EMF attributes initialised by the default
> values in the c++ object.
It's likely good for the EAttribute's default to match the default of
the object, but I'm not sure you would have such meta data.
>
> (3) Having the ResourceSet instance, how is it possible to present it
> in the EMF editor just like the static case?
Have you looked at a generated editor? They all look pretty much the
same...
>
> Ed Merks wrote:
>> Ali,
>>
>> Comments below.
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Thanks for making some points clear.
>> Sorry that I've been slightly less than my diplomatic best...
>>> Following your advice, here is a minimal simplified problem:
>>>
>>> Let's consider a simple thin wrapper java class as the existing code:
>>>
>>> public class WrapperClass {
>>> public void SetSomething(int value) {
>>> // Some call to JNI
>>> }
>>> public int GetSomething() {
>>> // Some call to JNI
>>> }
>>> }
>>>
>>> For now, we ignore how this class and its package can be
>>> automatically looked up and provided to the user. Given the above
>>> class, all we want is to:
>>>
>>> (1) Automatically detect the attributes and their types by simply
>>> matching SetX/GetX. Even this part is not EMF-related and may be
>>> ignored.
>> Probably you mean setX and getX, right?
>>>
>>> (2) Based on the class name and its attributes names and types,
>>> create a dynamic model where the user can instantiate the class in a
>>> reflective editor.
>> Yes, I could certainly imagine using Java reflection to gather such
>> information directly from the instance.
>>>
>>> Your suggestion involves starting from sub-classing EObject. How can
>>> this fit into the above? Does DynamicSet/DynamicGet have any use in
>>> this?
>> From what I understand, I think the following is a good start. I
>> imagine when you create objects you'll need to decide how to make
>> them wrap something and you'll need to make the reflectively method
>> do the JNI thing...
>>
>> package org.example;
>>
>> import org.eclipse.emf.common.util.URI;
>> import org.eclipse.emf.ecore.EAttribute;
>> import org.eclipse.emf.ecore.EClass;
>> import org.eclipse.emf.ecore.EObject;
>> import org.eclipse.emf.ecore.EPackage;
>> import org.eclipse.emf.ecore.EcoreFactory;
>> import org.eclipse.emf.ecore.EcorePackage;
>> import org.eclipse.emf.ecore.impl.DynamicEObjectImpl;
>> import org.eclipse.emf.ecore.impl.EFactoryImpl;
>> import org.eclipse.emf.ecore.resource.Resource;
>> import org.eclipse.emf.ecore.resource.ResourceSet;
>> import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
>> import org.eclipse.emf.ecore.util.Diagnostician;
>> import org.eclipse.emf.ecore.xmi.impl.XMLResourceFactoryImpl;
>>
>> public class Dynamic
>> {
>> interface Wrapper extends EObject
>> {
>> void setWrappedObject(Object object);
>> }
>>
>> static class MyDynamicEObjectImpl extends DynamicEObjectImpl
>> implements Wrapper
>> {
>> Object wrappedObject;
>>
>> public MyDynamicEObjectImpl(EClass eClass)
>> {
>> super(eClass);
>> }
>> public void setWrappedObject(Object object)
>> {
>> wrappedObject = object;
>> }
>> @Override
>> public Object eGet(int featureID, boolean resolve, boolean coreType)
>> {
>> System.out.println("how to use JNI to get " +
>> eClass().getEStructuralFeature(featureID).getName());
>> return super.eGet(featureID, resolve, coreType);
>> }
>>
>> @Override
>> public void eSet(int featureID, Object newValue)
>> {
>> System.out.println("how to use JNI to set " +
>> eClass().getEStructuralFeature(featureID).getName());
>> super.eSet(featureID, newValue);
>> }
>> }
>>
>> public static void main(String[] args) throws Exception
>> {
>> EPackage ePackage = EcoreFactory.eINSTANCE.createEPackage();
>> ePackage.setName("dynamic");
>> ePackage.setNsPrefix("dynamic");
>> ePackage.setNsURI("http://www.example.org/dynamic");
>> EClass eClass = EcoreFactory.eINSTANCE.createEClass();
>> eClass.setName("WrapperClass");
>> EAttribute eAttribute = EcoreFactory.eINSTANCE.createEAttribute();
>> eAttribute.setName("something");
>> eAttribute.setEType(EcorePackage.Literals.EINT);
>> eClass.getEStructuralFeatures().add(eAttribute);
>> ePackage.getEClassifiers().add(eClass);
>> System.out.println(Diagnostician.INSTANCE.validate(ePackage) );
>> {
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>> new XMLResourceFactoryImpl());
>> Resource resource =
>> resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
>> EObject eObject =
>> ePackage.getEFactoryInstance().create(eClass);
>> eObject.eSet(eAttribute, 10);
>> resource.getContents().add(eObject);
>> resource.save(System.out, null);
>> }
>> {
>> ePackage.setEFactoryInstance
>> (new EFactoryImpl()
>> {
>> @Override
>> protected EObject basicCreate(EClass eClass)
>> {
>> return new MyDynamicEObjectImpl(eClass);
>> }
>> });
>>
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>> new XMLResourceFactoryImpl());
>> Resource resource =
>> resourceSet.createResource(URI.createURI("file:/c:/dynamic.xml "));
>> Wrapper wrapper =
>> (Wrapper)ePackage.getEFactoryInstance().create(eClass);
>> wrapper.setWrappedObject(null);
>> wrapper.eSet(eAttribute, 10);
>> resource.getContents().add(wrapper);
>> resource.save(System.out, null);
>> }
>> }
>> }
>>
>>
>>>
>>> I hope the question is concrete and focused enough now. If this can
>>> be answered, I will have a base to continue.
>> It sounds like an interesting problem. Hopefully you'll share some of
>> your progress.
>>>
>>>
>>> Ed Merks wrote:
>>>> Ali,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Ali wrote:
>>>>> Ed,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Ali,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>>> How would you use Java Beans to wrap some existing hand-written
>>>>>>>> classes? That would be just as much work and there's no
>>>>>>>> solution for that either, right?
>>>>>>>
>>>>>>> Wrong, all we have to do to create Beans is to follow the name
>>>>>>> convention, the existing java code is actually generated by SWIG
>>>>>>> to wrap c++ objects. So, it is simple to automatically generate
>>>>>>> the naming convention and have the Beans *without* any code
>>>>>>> generation:
>>>>>>>
>>>>>>> [c++] -> [SWIG] -> [JavaBeans] -> [visual editor]
>>>>>> So SWIG could have generated EMF object instead of JavaBeans but
>>>>>> doesn't.
>>>>>
>>>>> SWIG is an automated c/c++ wrapper to many languages including
>>>>> java. SWIG cannot generate EMF objects directly, unless someone
>>>>> develops an extension of it to generate ecore xml files
>>>>> *directly*. However, like I mentioned this a couple of times,
>>>>> JavaBean objects may be generated *directly* from SWIG by simply
>>>>> following the name conventions. Eg, you can write a simple SWIG
>>>>> script which maps any c++ public methods starting with Get/Set to
>>>>> get/set and that should be enough to generate the accessors for
>>>>> the beans. This is not so straightforward in EMF.
>>>> It should be just as straight forward, but just doesn't exist yet.
>>>>> One could write a SWIG script to map any c++ public methods
>>>>> starting with Get/Set to Get/Set in java with an annotation before
>>>>> the java method to be used with EMF later. I have tried this
>>>>> approach once and encountered some unforeseen problems such as EMF
>>>>> crashing when generating code for 10^3 classes.
>>>> Crashing?
>>>>>
>>>>>>>
>>>>>>> I can also generate java annotations using SWIG to be used by
>>>>>>> EMF to generate static models:
>>>>>>>
>>>>>>> [c++] -> [SWIG] -> [annotated java] -> [ecore] -> [genmodel] ->
>>>>>>> [generated static code] -> [visual editor]
>>>>>>>
>>>>>>> I guess we both agree that automatic generation of annotated
>>>>>>> java is not as simple as following accessor naming convention.
>>>>>> It seems you could do SWIG -> Ecore?
>>>>>>> I was hoping the dynamic approach to be a work around for this
>>>>>>> longer process:
>>>>>>>
>>>>>>> [c++] -> [SWIG] -> [dynamic EMF] -> [visual editor]
>>>>>> So that's SWIG to Ecore but I don't know what SWIG is. Given
>>>>>> that Java bean solution is static code generation, it makes me
>>>>>> wonder again why you are taking a dynamic approach...
>>>>>
>>>>> The above comment explains one of the reasons why I am trying to
>>>>> consider the dynamic approach now, as the dynamic approach skips
>>>>> code generation. In practice, the user would not generate
>>>>> thousands of objects and only a small sub-sample from the pool of
>>>>> objects will be used in an EMF document--from this point of view,
>>>>> it makes sense to generate the model for that small sub-sample at
>>>>> run-time and leave the rest of the pool. Section 13.6 of the EMF
>>>>> book explains how to create a dynamic model at run-time as well as
>>>>> instantiating it programmatically. However, it does not say how it
>>>>> is possible to have the editor to use the dynamic model. Am I
>>>>> missing a point here?
>>>> The reflective editor uses a dynamic model.
>>>>>
>>>>> As you have been developing EMF for years, it could be difficult
>>>>> for you to feel the fuzziness of implementing the dynamic approach
>>>>> without much documentation or examples for outsiders.
>>>> Yes, it's hard to keep track of what's obvious and what's totally not.
>>>>> I do appreciate the prompt help in the newsgroup though.
>>>> Probably it would be good to start to dive in and ask more specific
>>>> focused questions. For example, I'm sure you will need to create
>>>> your own derived EObject implementation and hence you'll end up
>>>> wanting a derived EFactoryImpl that overrides this method:
>>>>
>>>> protected EObject basicCreate(EClass eClass)
>>>> {
>>>> return
>>>> eClass.getInstanceClassName() == "java.util.Map$Entry" ?
>>>> new DynamicEObjectImpl.BasicEMapEntry<String,
>>>> String>(eClass) :
>>>> new DynamicEObjectImpl(eClass);
>>>> }
>>>>
>>>> And you'll want to set this into your EPackage. I would focus
>>>> first on getting your scenario working in a simple non-GUI scenario
>>>> and build up from there...
>>>>>
>>>>>>
>>>>>>>
>>>>>>> , but, as you wrote, it is trickier. So, back to square one.
>>>>>>>
>>>>>>>>> This is the reason I am asking for examples before investing
>>>>>>>>> time on coding based on the wrong design.
>>>>>>>> It's not so clear what you're trying to get from EMF. If you
>>>>>>>> already have beans and are happy with them, then you don't
>>>>>>>> really need EMF.
>>>>>>>
>>>>>>> Needless to say, I am trying to use EMF as a gate to
>>>>>>> automatically import the objects to the eclipse platform. As far
>>>>>>> as I know there is no support for Beans in eclipse and,
>>>>>>> conversely, there is no equivalent of eclipse for Beans.
>>>>>> The data binding framework supports beans. But beans don't do
>>>>>> much all on their own.
>>>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:33:26 GMT 2024
Powered by FUDForum. Page generated in 0.04587 seconds |
] 
Search
Help
Register
Login
Home
