Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » I need "static" model fields, what is the best way?
I need "static" model fields, what is the best way? [message #1043039] Wed, 17 April 2013 07:36 Go to next message
Mauro Condarelli is currently offline Mauro CondarelliFriend
Messages: 428
Registered: September 2009
Senior Member
Hi,
in my model, in several places, I have something like a "type" of the object.
This type is really part of the model itself, i.e.: I can add new "types" and these should become available to all objects.

I mean:

public interface Plant {
...
/** model containment="true" */
EList<Machine> getMachine();
...
}

public interface Machine {
...
Type getType();
/** model containment="false" ?what else? */
List<Type> getTypes();
...
}

Or would it be better to put the list of possible types somewhere else?
The only workaround I found is to attache ALL such lists (there are many!) to the root node of my model, but that's really ugly because many of these do not really belong there.

What are the "best practices" in this case?

One obvious use of such a thing is to prepare a combo box to select the actual machine type given the defined ones.

Thanks in advance
Mauro
Re: I need &quot;static&quot; model fields, what is the best way? [message #1043173 is a reply to message #1043039] Wed, 17 April 2013 11:20 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Mauro,

Comments below.

On 17/04/2013 9:36 AM, Mauro Condarelli wrote:
> Hi,
> in my model, in several places, I have something like a "type" of the
> object.
Is that different from the Java getClass() or the EMF eClass()?
> This type is really part of the model itself, i.e.: I can add new
> "types" and these should become available to all objects.
>
> I mean:
>
> public interface Plant {
> ...
> /** model containment="true" */
> EList<Machine> getMachine();
> ...
> }
>
> public interface Machine {
> ...
> Type getType();
> /** model containment="false" ?what else? */
> List<Type> getTypes();
> ...
> }
>
> Or would it be better to put the list of possible types somewhere else?
Or use an enumeration?
> The only workaround I found is to attache ALL such lists (there are
> many!) to the root node of my model, but that's really ugly because
> many of these do not really belong there.
I don't follow what the purpose is.
>
> What are the "best practices" in this case?
>
> One obvious use of such a thing is to prepare a combo box to select
> the actual machine type given the defined ones.
How are new types created?
>
> Thanks in advance
> Mauro


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: I need &quot;static&quot; model fields, what is the best way? [message #1043258 is a reply to message #1043173] Wed, 17 April 2013 13:29 Go to previous messageGo to next message
Mauro Condarelli is currently offline Mauro CondarelliFriend
Messages: 428
Registered: September 2009
Senior Member
Thanks for the quick answer Ed.
Comments are inline.

Regards
Mauro

Ed Merks wrote on Wed, 17 April 2013 07:20
Mauro,

Comments below.

On 17/04/2013 9:36 AM, Mauro Condarelli wrote:
> Hi,
> in my model, in several places, I have something like a "type" of the
> object.
Is that different from the Java getClass() or the EMF eClass()?

Yes, "Type" is an user-defined EObject; it may be as simple as a String and an automatically generated reference number or it can contain several properties.


> This type is really part of the model itself, i.e.: I can add new
> "types" and these should become available to all objects.
>
> I mean:
>
> public interface Plant {
> ...
> /** model containment="true" */
> EList<Machine> getMachine();
> ...
> }
>
> public interface Machine {
> ...
> Type getType();
> /** model containment="false" ?what else? */
> List<Type> getTypes();
> ...
> }
>
> Or would it be better to put the list of possible types somewhere else?
Or use an enumeration?

Can I dinamically add elements to an enumeration?
The number of "Type"s is not fixed.


> The only workaround I found is to attache ALL such lists (there are
> many!) to the root node of my model, but that's really ugly because
> many of these do not really belong there.
I don't follow what the purpose is.

Let me try to explain with a very simple case; If I were to write a set of normal Java classes I would write something like:

class Foo {
   static List<Bar> bars = ...;
   static addBar(Bar bar) {
      bars.add(bar);
   }
   
   Bar myBar = null;

   public void choseBar() {
      Here display a Combo with bars as definition of the Combo.items,
      Select one of the possible "bar" and put it in "myBar"
      Dialog should also have an [Add] button to call addBar(), 
      update Combo.items and preselect the new value.
   }

   public boolean addBar() {
      Here display a dialog to edit a brand new "Bar" and,
      if confirmed, add it to "bars";
   }
}

class Bar {
   private final String name;
   private final int index;
   private static int count = 0;
   ...
   public Bar(String name) {
      this.name = name;
      index = count++;
   }
   public getName() {
      return name;
   }
   public getIndex() {
      return index;
   }
   ...
} 



>
> What are the "best practices" in this case?
>
> One obvious use of such a thing is to prepare a combo box to select
> the actual machine type given the defined ones.
How are new types created?
Types (and other similar objects) are created globally by the user.
User may create them beforehand or, whrever there is the possibility to chose one there should also be a way (button, most likely) to create a new one if a suitable one cannot be found.

As I've tried to explain these "types" are local to some other class instance, but the whole list is global to all instances of that class.

Sometimes I have such a simple "type", some other times I have a list of characteristics (something like multiple keywords) attached... always taken from a global list that should be saved and restored with the model.

As said usually this "type" or "keyword" is quite simple, but it can be arbitrarily complex. In any cases these are used either in a single EObject or in a small number of related EObjects; i.e.: each EObject has it's own set of possible "types"

>
> Thanks in advance
> Mauro


Sorry for the lenght of this, but I wanted to be sure to make my problem clear.

TiA again
Mauro
Re: I need &amp;quot;static&amp;quot; model fields, what is the best way? [message #1043284 is a reply to message #1043258] Wed, 17 April 2013 14:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Mauro,

Comments below.


On 17/04/2013 3:29 PM, Mauro Condarelli wrote:
> Thanks for the quick answer Ed.
> Comments are inline.
>
> Regards
> Mauro
>
> Ed Merks wrote on Wed, 17 April 2013 07:20
>> Mauro,
>>
>> Comments below.
>>
>> On 17/04/2013 9:36 AM, Mauro Condarelli wrote:
>> > Hi,
>> > in my model, in several places, I have something like a "type" of
>> the > object.
>> Is that different from the Java getClass() or the EMF eClass()?
>>
>> Yes, "Type" is an user-defined EObject; it may be as simple as a
>> String and an automatically generated reference number or it can
>> contain several properties.
Sounds much like an Ecore model though...
>>
>>
>> > This type is really part of the model itself, i.e.: I can add new >
>> "types" and these should become available to all objects.
>> >
>> > I mean:
>> >
>> > public interface Plant {
>> > ...
>> > /** model containment="true" */
>> > EList<Machine> getMachine();
>> > ...
>> > }
>> >
>> > public interface Machine {
>> > ...
>> > Type getType();
>> > /** model containment="false" ?what else? */
>> > List<Type> getTypes();
>> > ...
>> > }
>> >
>> > Or would it be better to put the list of possible types somewhere
>> else?
>> Or use an enumeration?
>>
>> Can I dinamically add elements to an enumeration?
No.
>> The number of "Type"s is not fixed.
The structure of your types and their relations to their instances (hmm,
is that the right concept), is very vague still...
>>
>>
>> > The only workaround I found is to attache ALL such lists (there are
>> > many!) to the root node of my model, but that's really ugly because
>> > many of these do not really belong there.
>> I don't follow what the purpose is.
>>
>> Let me try to explain with a very simple case; If I were to write a
>> set of normal Java classes I would write something like:
>>
>>
>> class Foo {
>> static List<Bar> bars = ...;
>> static addBar(Bar bar) {
>> bars.add(bar);
>> }
>> Bar myBar = null;
>>
>> public void choseBar() {
>> Here display a Combo with bars as definition of the Combo.items,
>> Select one of the possible "bar" and put it in "myBar"
>> Dialog should also have an [Add] button to call addBar(),
>> update Combo.items and preselect the new value.
>> }
>>
>> public boolean addBar() {
>> Here display a dialog to edit a brand new "Bar" and,
>> if confirmed, add it to "bars";
>> }
>> }
>>
>> class Bar {
>> private final String name;
>> private final int index;
>> private static int count = 0;
>> ...
>> public Bar(String name) {
>> this.name = name;
>> index = count++;
>> }
>> public getName() {
>> return name;
>> }
>> public getIndex() {
>> return index;
>> }
>> ...
>> }
>>
>>
>> >
>> > What are the "best practices" in this case?
>> >
>> > One obvious use of such a thing is to prepare a combo box to select
>> > the actual machine type given the defined ones.
>> How are new types created?
>> Types (and other similar objects) are created globally by the user.
>> User may create them beforehand or, whrever there is the possibility
>> to chose one there should also be a way (button, most likely) to
>> create a new one if a suitable one cannot be found.
>>
>> As I've tried to explain these "types" are local to some other class
>> instance, but the whole list is global to all instances of that class.
>>
>> Sometimes I have such a simple "type", some other times I have a list
>> of characteristics (something like multiple keywords) attached...
>> always taken from a global list that should be saved and restored
>> with the model.
And why doesn't the user just create subclasses?
>>
>> As said usually this "type" or "keyword" is quite simple, but it can
>> be arbitrarily complex. In any cases these are used either in a
>> single EObject or in a small number of related EObjects; i.e.: each
>> EObject has it's own set of possible "types"
>>
>> >
>> > Thanks in advance
>> > Mauro
>
>
> Sorry for the lenght of this, but I wanted to be sure to make my
> problem clear.
Sorry, it's quite confusing because all this Foo Bar stuff doesn't tell
me concretely what any of this really means...
>
> TiA again
> Mauro


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: I need &amp;quot;static&amp;quot; model fields, what is the best way? [message #1043323 is a reply to message #1043284] Wed, 17 April 2013 15:00 Go to previous messageGo to next message
Mauro Condarelli is currently offline Mauro CondarelliFriend
Messages: 428
Registered: September 2009
Senior Member
Sorry Ed,

I'll try with a real example of what I need to do and ask what is, in your opinion, the Right Way to implement it.

In a Module I need to do computations using data coming from the field.
Each computation is defined as a list of basic operations.
Each operation is a mathematical expression involving measured data.
These operations should be reused wherever possible (some background process loops over the Operations recomputing results).

In this condition I have a global EList<Operation>(containment="true") together with some means to add, delete and generally edit new Operations.
I also have a "class Computation extends EObject" that includes EList<Operation>(containment="false").
As I can have instances of Computation scattered around my model the only way I found is to attach the full list to the root of the model and add references in the various Computation objects (Computation objects do their things just using the results computed).

Since the global EList<Operation>(containment="true") is used ONLY in instances of Computation I would like to segregate it there.
This would mean to have a kind of static EList common to all instances.
I don't know if this is possible or what are the other "good" alternatives.

TiA
Mauro
Re: I need &amp;amp;quot;static&amp;amp;quot; model fields, what is the best way? [message #1043799 is a reply to message #1043323] Thu, 18 April 2013 06:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Mauro,

Comments below.

On 17/04/2013 5:00 PM, Mauro Condarelli wrote:
> Sorry Ed,
>
> I'll try with a real example of what I need to do and ask what is, in
> your opinion, the Right Way to implement it.
>
> In a Module I need to do computations using data coming from the field.
> Each computation is defined as a list of basic operations.
> Each operation is a mathematical expression involving measured data.
> These operations should be reused wherever possible (some background
> process loops over the Operations recomputing results).
>
> In this condition I have a global EList<Operation>(containment="true")
> together with some means to add, delete and generally edit new
> Operations.
> I also have a "class Computation extends EObject" that includes
> EList<Operation>(containment="false").
I see.
> As I can have instances of Computation scattered around my model the
> only way I found is to attach the full list to the root of the model
> and add references in the various Computation objects (Computation
> objects do their things just using the results computed).
They could also be contained in a completely separate resource.
>
> Since the global EList<Operation>(containment="true") is used ONLY in
> instances of Computation I would like to segregate it there.
> This would mean to have a kind of static EList common to all instances.
Or some kind of library resource that's shared across instances.
> I don't know if this is possible or what are the other "good"
> alternatives.
Not really. It's better to consider this more like a shared library.
>
> TiA
> Mauro
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: I need &amp;amp;quot;static&amp;amp;quot; model fields, what is the best way? [message #1044725 is a reply to message #1043799] Fri, 19 April 2013 08:47 Go to previous messageGo to next message
Mauro Condarelli is currently offline Mauro CondarelliFriend
Messages: 428
Registered: September 2009
Senior Member
Thanks Ed.
I do understand this in principle, but I only have a foggy idea about how to realize it in practice.

Do you mean I should construct completely separate models for the "true model" and for the (several) shared libs?
Or can a single model insist on multiple resources?

Can You point me to some example of such an arrangement, please?

TiA
Mauro

> > instances of Computation I would like to segregate it there.
> > This would mean to have a kind of static EList common to all instances.
> Or some kind of library resource that's shared across instances.
> > I don't know if this is possible or what are the other "good"
> > alternatives.
> Not really. It's better to consider this more like a shared library.
Re: I need &amp;amp;amp;quot;static&amp;amp;amp;quot; model fields, what is the best way? [message #1044754 is a reply to message #1044725] Fri, 19 April 2013 09:44 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Mauro,

Comments below.

On 19/04/2013 10:47 AM, Mauro Condarelli wrote:
> Thanks Ed.
> I do understand this in principle, but I only have a foggy idea about
> how to realize it in practice.
>
> Do you mean I should construct completely separate models for the
> "true model" and for the (several) shared libs?
No, that's not necessary.
> Or can a single model insist on multiple resources?
Of course instances can span resources and that's completely orthogonal
to how many models are involved.
>
> Can You point me to some example of such an arrangement, please?
I can give examples of Ecore itself, but I think that would just get
confusing....

I suggest you start by trying to split your instances across resources
just to understand how that works.

The decision you'll need to make about a "library" resource is where
does it live? If it's a static thing, it could be literally just part
of the jarred bundle that you ship, much like org.eclipse.emf.ecore
contains model/Ecore.ecore and is accessible (loadable) via
platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore. If it's
something the user modifies, it should probably be somewhere in the
workspace.
>
> TiA
> Mauro
>
>> > instances of Computation I would like to segregate it there.
>> > This would mean to have a kind of static EList common to all
>> instances.
>> Or some kind of library resource that's shared across instances.
>> > I don't know if this is possible or what are the other "good" >
>> alternatives.
>> Not really. It's better to consider this more like a shared library.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[Teneo] @Columns annotation does not work
Next Topic:[CDO] Migrate Repository when Ecore changes
Goto Forum:
  


Current Time: Tue Mar 19 05:16:28 GMT 2024

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

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

Back to the top