Skip to main content



      Home
Home » Archived » Visual Editor (VE) » What is the need for EMF model when BeanDeclModel is being built?
What is the need for EMF model when BeanDeclModel is being built? [message #68643] Thu, 21 October 2004 12:11 Go to next message
Eclipse UserFriend
Hi All,

I am trying to provide a GUI editor for a 4GL language. I have looked at
the VE architecture and I have prototyped it for 4GL language and gotten
following trip to work by reusing some of the VE architecture and code -

4GL code -> AST(ANTLR) -> bean declatation model(BDM) -> EMF instance
model (EObject) -> controller -> view

The controller and view are based on GEF.

Now, I need to wire the adaptors to get the update working. While I do
that, I am debating the need for "EMF instance model" as the BDM with a
thin wrapper for IPropertySource can provide the same functionality and
avoid the adapter wiring and associated event complications and make it
easier to maintain the code.

Any thoughts on:
1. If the proposed shortcut is a good idea for my case
2. Why Visual Editor project has used BDM-EMF separation layer would be
greatly appreciated.

Regards,

Sunil.
Re: What is the need for EMF model when BeanDeclModel is being built? [message #68650 is a reply to message #68643] Fri, 22 October 2004 09:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

We are using EMF as the basic model in the VE becauase it provides a
highlevel abstraction instead of the BDM. The BDM is explicitly specific
to Java code parsing, and for generating java code. The rest of the VE
works off of EMF entirely to allow generic contributions, notification,
and serialization. It allows common concepts of a VE to be non-java
specific. It even allows us to do modeling of java object compostion
without having any java code as the model (i.e. no .java file to parse).


--
Thanks,
Rich Kulp
Re: What is the need for EMF model when BeanDeclModel is being built? [message #68668 is a reply to message #68643] Fri, 22 October 2004 09:48 Go to previous message
Eclipse UserFriend
Originally posted by: mendelgili.netscape.net

Sunil Belgaonkar wrote:

> Hi All,
>
> I am trying to provide a GUI editor for a 4GL language. I have looked at
> the VE architecture and I have prototyped it for 4GL language and gotten
> following trip to work by reusing some of the VE architecture and code -
>
> 4GL code -> AST(ANTLR) -> bean declatation model(BDM) -> EMF instance
> model (EObject) -> controller -> view
>
> The controller and view are based on GEF.
>
> Now, I need to wire the adaptors to get the update working. While I do
> that, I am debating the need for "EMF instance model" as the BDM with a
> thin wrapper for IPropertySource can provide the same functionality and
> avoid the adapter wiring and associated event complications and make it
> easier to maintain the code.
>
> Any thoughts on:
> 1. If the proposed shortcut is a good idea for my case
> 2. Why Visual Editor project has used BDM-EMF separation layer would be
> greatly appreciated.
>
> Regards,
>
> Sunil.
>

Sounds like a cool project!

The center of the VE universe is the EMF model... this is "the" VE model and is a generic representation of Java object
instances, their properties settings, scope, events etc. The VE model cares not of source code, visual representation
and can be searilzed (as XMI).

The BDM is used by the CodeGen "adapter". The BDM is a ref. model that maintains mappings to/from relevant expressions
in the source to their corresponding elements in the VE model.


instance/local variable <--- BeanPart ---> IJavaInstance
property setting expression <--- CodeExpressionRef --> property settings
....


..... so for instance, if you select a visual, the editor will use the codegen adapter (using the BDM) to drive the
source editor to the location of where the instance is created... if you select a property on the PropertySheet the
editor will use codegen to drive to the expression that sets this property etc.


For 4GL support, if you want an interactive visual/source... you will have to create a BDM like mapping. If you want to
provide a tabbed (switch) editor only, the problem is much simpler... and all you need to do is provide serialization
support for the VE EMF model
Re: What is the need for EMF model when BeanDeclModel is being built? [message #602203 is a reply to message #68643] Fri, 22 October 2004 09:09 Go to previous message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

We are using EMF as the basic model in the VE becauase it provides a
highlevel abstraction instead of the BDM. The BDM is explicitly specific
to Java code parsing, and for generating java code. The rest of the VE
works off of EMF entirely to allow generic contributions, notification,
and serialization. It allows common concepts of a VE to be non-java
specific. It even allows us to do modeling of java object compostion
without having any java code as the model (i.e. no .java file to parse).


--
Thanks,
Rich Kulp
Re: What is the need for EMF model when BeanDeclModel is being built? [message #602230 is a reply to message #68643] Fri, 22 October 2004 09:48 Go to previous message
Eclipse UserFriend
Sunil Belgaonkar wrote:

> Hi All,
>
> I am trying to provide a GUI editor for a 4GL language. I have looked at
> the VE architecture and I have prototyped it for 4GL language and gotten
> following trip to work by reusing some of the VE architecture and code -
>
> 4GL code -> AST(ANTLR) -> bean declatation model(BDM) -> EMF instance
> model (EObject) -> controller -> view
>
> The controller and view are based on GEF.
>
> Now, I need to wire the adaptors to get the update working. While I do
> that, I am debating the need for "EMF instance model" as the BDM with a
> thin wrapper for IPropertySource can provide the same functionality and
> avoid the adapter wiring and associated event complications and make it
> easier to maintain the code.
>
> Any thoughts on:
> 1. If the proposed shortcut is a good idea for my case
> 2. Why Visual Editor project has used BDM-EMF separation layer would be
> greatly appreciated.
>
> Regards,
>
> Sunil.
>

Sounds like a cool project!

The center of the VE universe is the EMF model... this is "the" VE model and is a generic representation of Java object
instances, their properties settings, scope, events etc. The VE model cares not of source code, visual representation
and can be searilzed (as XMI).

The BDM is used by the CodeGen "adapter". The BDM is a ref. model that maintains mappings to/from relevant expressions
in the source to their corresponding elements in the VE model.


instance/local variable <--- BeanPart ---> IJavaInstance
property setting expression <--- CodeExpressionRef --> property settings
....


..... so for instance, if you select a visual, the editor will use the codegen adapter (using the BDM) to drive the
source editor to the location of where the instance is created... if you select a property on the PropertySheet the
editor will use codegen to drive to the expression that sets this property etc.


For 4GL support, if you want an interactive visual/source... you will have to create a BDM like mapping. If you want to
provide a tabbed (switch) editor only, the problem is much simpler... and all you need to do is provide serialization
support for the VE EMF model
Previous Topic:Adding to the Palette
Next Topic:Linux work spaces
Goto Forum:
  


Current Time: Wed May 07 19:25:18 EDT 2025

Powered by FUDForum. Page generated in 0.03750 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top