[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Default Value of an inherited EAttribute or EReference
Thanks Ed. I will look into the idea of generating convenience methods in the factory to populate an instance and leave the default factory methods alone.

JT


Ed Merks wrote:

John,

Comments below.

John T.E. Timm wrote:
Thanks Ed. That takes care of EAttribute defaults. Though I still need some sort of initialization code for EReferences in certain cases. I think the FactoryClass.javajet customization is the best way to do this, where I do something like this:

// In createXXX
1. Instantiate class
2. Look at some custom annotations to decide what to do and get reference attribute values.
3. Create EReference instance and set reference attribute values appropriately
4. Add references to Class
I'm having trouble with the meta levels here.

It would be a pain for the client code to do all this set-up, especially if the EReference attribute
Here too, the word attribute throws me... 
values are essentially fixed. Given this model:

// One Ecore
ClassA : EClass
 ref [*] : ClassB

// Some Other Ecore
ClassB : EClass
 attr : EString

I really want to generate something like this in the factory method for ClassA:

public ClassA createClassA() {
 ClassAImpl classA = new ClassAImpl();
 ClassB classB = SomeOtherFactory.eINSTANCE.createClassB();
 classB.setAttr("1");
 classA.getRef().add(classB);
 classB = SomeOtherFactory.eINSTANCE.createClassB();
 classB.setAttr("2");
 classA.getRef().add(classB);
 classB = SomeOtherFactory.eINSTANCE.createClassB();
 classB.setAttr("3");
 classA.getRef().add(classB);
 return classA;
The problem with this will be with things like copying and deserialization as you'll find out, if you try it. I'd suggest adding convenience methods to the factory but do not touch the base methods which must created bare unpopulated instances. 
}

Thanks,

JT

Ed Merks wrote:

John,

Comments below.

John T.E. Timm wrote:
So let's say that I define an EOperation "getFoo" in superclass A. And then I define an EAttribute "foo" in subclass B. Are you suggesting that I use the "Default Literal" option in conjunction with OPTION_KEEP_DEFAULT_CONTENT on EAttribute foo in subclass B so that the default gets serialized?
I'm just suggesting that when defining the feature just in "B" it's business as usual. Define a default there and things will work as expected/always.

In my particular application, I actually always want attr to be serialized.
That options works well for that when you define a default too.
So I guess what I am looking for is a way to "initialize" the value of certain EAttributes and EReferences
Forget EReferences since that's incredibly unlikely to work well.
immediately after instantiation without forcing the client code to do it explicitly... In my particular model, I would have a superclass A with subclasses B, C, and D where the only difference with B, C, and D is that there are some constraints added and I want to "initialize" the value of certain EAttributes and EReferences differently.
So the operation on A approach might work well then. 

Thanks,

JT

Ed Merks wrote:

John,

Comments below.

John T.E. Timm wrote: 
Ed:

Ed Merks wrote:

"Or have just an operation on A with a name that is overloaded by the attribute in B..."

Could you please expain how this would work?
On A you define an operation getFoo and in B you define a feature "foo" which will implement getFoo.

What about attaching annotations to the class with all of the default or fixed values and then customizing the generated EFactory to do something like this:

public ClassB createClassB() {
ClassB instance = new ClassBImpl();
// look at annotations to determine what needs to be initialized here
instance.setAttr("someValue");
// ...
}
You'll find that eIsSet returns true for "attr", so this value will be serialized, unlike what a true default would do. If you unset "attr" and made a copy of ClassB, you'd find "attr" would be set in the copy but not in the original. 

Thanks,

JT