Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Provide context specific "views" on an EObject
Provide context specific "views" on an EObject [message #1020457] Mon, 18 March 2013 08:19 Go to next message
Johannes Wachter is currently offline Johannes WachterFriend
Messages: 2
Registered: March 2013
Junior Member
Hi,

in my project we are currently using EMF as the representation for our central data structures. We also have modeled our main data representation layer like the following (XCore Style notation):

class EntityDescription {
  String tableName
  ColumnDescription [] columns
  boolean userEditable
  ...
}

class Entity {
  String uiniqueId
  Date updateTime
  ...
}


Both data structures are dependant on the configuration of the backend system that is used. The EntityDescription is a fixed data structure that is populated dynamically from the backend configuration. For the Entity we create a dynamic Sub-EClass that contains the features for all the columns configured in the backend.

To support different views onto this classes we are now thinking about how to provide a solution to both

- be able to hide columns in both classes depending on the context
- be able to add additional columns that are updated by an Adapter and don't really exist in the backend

Our current thinking is to create modeled classes for the Views onto the Entity and EntityDescription that contain a reference to their original. In addition we think about dynamically creating a subclass of the view onto Entity that contains the additional features.

class EntityDescriptionView {
	refers EntityDescription baseDescription
}

class EntityView {
  refers Entity baseEntity
  String someAdditionalFeature
  ...
}


The important thing for us is that the view should behave like the original instance just with another feature set so that our EMF feature based data binding just works as well with a view as with the original. Therefore we're thinking of implementing a Proxy class that implements the EObject interface and that directs calls to features either to the views additional features or the original Entity's features.

(pseudo code)
class EntityViewProxy implements EObject {
	if(view contains feature){
		redirect to view
	} else {
		redirect to base entity
	}
}


The question now is if that is a good way to provide such a solution with EMF or if there is a better, more "EMF-like" way of achieving the goal.
Re: Provide context specific "views" on an EObject [message #1020904 is a reply to message #1020457] Tue, 19 March 2013 06:38 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26285
Registered: July 2009
Senior Member
Johannes,

comments below.

On 18/03/2013 7:01 PM, Johannes Wachter wrote:
> Hi,
>
> in my project we are currently using EMF as the representation for our
> central data structures. We also have modeled our main data
> representation layer like the following (XCore Style notation):
>
>
> class EntityDescription {
> String tableName
> ColumnDescription [] columns
> boolean userEditable
> ...
> }
>
> class Entity {
> String uiniqueId
> Date updateTime
> ...
> }
>
>
> Both data structures are dependant on the configuration of the backend
> system that is used. The EntityDescription is a fixed data structure
> that is populated dynamically from the backend configuration. For the
> Entity we create a dynamic Sub-EClass that contains the features for
> all the columns configured in the backend.
>
> To support different views onto this classes we are now thinking about
> how to provide a solution to both
>
> - be able to hide columns in both classes depending on the context
Is the context decided by the view? You might annotate the features of
the model with information the view can use to decide if it should show
that feature.
> - be able to add additional columns that are updated by an Adapter
> and don't really exist in the backend
This information is transient? Why wouldn't you model it as a subclass
with that feature?
>
> Our current thinking is to create modeled classes for the Views onto
> the Entity and EntityDescription that contain a reference to their
> original. In addition we think about dynamically creating a subclass
> of the view onto Entity that contains the additional features.
>
>
> class EntityDescriptionView {
> refers EntityDescription baseDescription
> }
>
> class EntityView {
> refers Entity baseEntity
> String someAdditionalFeature
> ...
> }
>
>
> The important thing for us is that the view should behave like the
> original instance just with another feature set so that our EMF
> feature based data binding just works as well with a view as with the
> original. Therefore we're thinking of implementing a Proxy class that
> implements the EObject interface and that directs calls to features
> either to the views additional features or the original Entity's
> features.
>
>
> (pseudo code)
> class EntityViewProxy implements EObject {
> if(view contains feature){
> redirect to view
> } else {
> redirect to base entity
> }
> }
No, you can't implement the EObject API directly, you must subclass
BasicEObjectImpl or something below it. And you can't override equals
so a proxy will always be distingishable from the original...
>
>
> The question now is if that is a good way to provide such a solution
> with EMF or if there is a better, more "EMF-like" way of achieving the
> goal.

A better approach is likely to make Entity and EntityDescription
annotatable much like EModelElement has EAnnotations. It's not clear
you even need that. Hiding could be accomplished by annotating the
EStructuralFeatures in some suitable way. Additional information could
be associated via stateful adapters (item providers).
Re: Provide context specific "views" on an EObject [message #1020916 is a reply to message #1020904] Tue, 19 March 2013 07:08 Go to previous messageGo to next message
Johannes Wachter is currently offline Johannes WachterFriend
Messages: 2
Registered: March 2013
Junior Member
Hi Ed,

thanks for your response.

Concerning your comments:

Perhaps the term view was a bad choice, it's more like our framework chooses which features are allowed to be seen (and edited) by a 3rd party form showing a certain entity type.

The additionally added features are transient since they are normally calculated based upon other features in the same class. I had the idea with the idea to solve it via a subclass but I was concerned about duplicating and synchronizing all the information between the original instance and the subclass. For that we would essentially need an Adapter that relays all Notifications in both directions if im correct? Or is there a more lightweight solution I'm not aware of?

Concerning your last comment with stateful adapters: This seems to be a good solution but would mean to lose the nature of the EObject since we can only react to "set" calls but not to "get" calls which would be the interesting thing in our case.

Regards,
Johannes

Re: Provide context specific "views" on an EObject [message #1021040 is a reply to message #1020916] Tue, 19 March 2013 12:23 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26285
Registered: July 2009
Senior Member
Johannes,

Comments below.

On 19/03/2013 8:08 AM, Johannes Wachter wrote:
> Hi Ed,
>
> thanks for your response.
>
> Concerning your comments:
>
> Perhaps the term view was a bad choice, it's more like our framework
> chooses which features are allowed to be seen (and edited) by a 3rd
> party form showing a certain entity type.
I see.
>
> The additionally added features are transient since they are normally
> calculated based upon other features in the same class.
Transient and derived...
> I had the idea with the idea to solve it via a subclass but I was
> concerned about duplicating and synchronizing all the information
> between the original instance and the subclass.
Yes that could be quite a bit of work.
> For that we would essentially need an Adapter that relays all
> Notifications in both directions if im correct? Or is there a more
> lightweight solution I'm not aware of?
Not really.
>
> Concerning your last comment with stateful adapters: This seems to be
> a good solution but would mean to lose the nature of the EObject since
> we can only react to "set" calls but not to "get" calls which would be
> the interesting thing in our case.
I see.
>
> Regards,
> Johannes
>
>
Previous Topic:Regression in URI parsing?
Next Topic:Eclipse CodeWarrior 10.3 problem
Goto Forum:
  


Current Time: Sat Dec 20 14:35:59 GMT 2014

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

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