Home » Modeling » EMF » Restrict visibility in editors
| Restrict visibility in editors [message #414667] |
Fri, 16 November 2007 11:15  |
 Morten MacFly
Messages: 69
Registered: July 2009 |
Member |
|
|
Dear all,
I guess I have to explain somthing before the actual question, so here
it goes: I have an EMF model like this:
MyModel
|-ElemType1{ElemType1Attr1, ElemType1Attr2, ...}
|-ElemType2{ElemType2Attr1, ElemType2Attr2, ...}
--ElemType3{ElemType3Attr1, ElemType3Attr2, ...}
Each [ElemType{1,2,3}Implementation] has in addition to it's usual
generated methods another method like "bool isVisible(featureID);". I
realised that by modifying the template that generates the classes.
Now I want to achieve that in the editors according to how the
visibility flags are initialised those elements are present or not. This
means the complete sub-tree or within leaves only some attributes are
(in)visible.
In "MyModelPackageImpl" I now would therefore like to modify
initializePackageContents() and createPackageContents() accordingly so
that these elements are *not* being created. So I need something like:
elemType1EClass = createEClass(ELEM_TYPE1_ID);
if (ElemType1Impl.isVisible(ELEM_TYPE1_ATTR1_ID) {
createEAttribute(elemType1EClass, ELEM_TYPE1_ATTR1_ID);
}
But how do I access the implementation class in a "right" way, actually?
(Cause I need the specific implementation of this "ElemType", obviously)?
With regards, Martin.
|
|
|
| Re: Restrict visibility in editors [message #414679 is a reply to message #414667] |
Fri, 16 November 2007 11:50  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Morten,
Comments below.
Morten MacFly wrote:
> Dear all,
>
> I guess I have to explain somthing before the actual question, so here
> it goes: I have an EMF model like this:
>
> MyModel
> |-ElemType1{ElemType1Attr1, ElemType1Attr2, ...}
> |-ElemType2{ElemType2Attr1, ElemType2Attr2, ...}
> --ElemType3{ElemType3Attr1, ElemType3Attr2, ...}
>
> Each [ElemType{1,2,3}Implementation] has in addition to it's usual
> generated methods another method like "bool isVisible(featureID);". I
> realised that by modifying the template that generates the classes.
> Now I want to achieve that in the editors according to how the
> visibility flags are initialised those elements are present or not. This
> means the complete sub-tree or within leaves only some attributes are
> (in)visible.
> In "MyModelPackageImpl" I now would therefore like to modify
> initializePackageContents() and createPackageContents() accordingly so
> that these elements are *not* being created. So I need something like:
>
> elemType1EClass = createEClass(ELEM_TYPE1_ID);
> if (ElemType1Impl.isVisible(ELEM_TYPE1_ATTR1_ID) {
> createEAttribute(elemType1EClass, ELEM_TYPE1_ATTR1_ID);
> }
>
This part really confuses me. The visibility state is controlled per
instance but you are talking about change the metamodel itself which
affects all instances.
> But how do I access the implementation class in a "right" way, actually?
> (Cause I need the specific implementation of this "ElemType", obviously)?
>
You'd clearly need multiple EClasses, not a single shared one. Are you
sure you shouldn't just be modifying the property descriptors to
selectively filter out certain properties or children depending on the
state of the instance?
> With regards, Martin.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Restrict visibility in editors [message #414687 is a reply to message #414682] |
Fri, 16 November 2007 12:51 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090806060705050707040009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Morten,
Comments below.
Morten MacFly wrote:
> Ed Merks wrote:
>
>> This part really confuses me. The visibility state is controlled per
>> instance but you are talking about change the metamodel itself which
>> affects all instances.
>>
> Yes! That's exactly what I want to achieve. This means that according to
> what config I load on startup of the application all (!) editors use a
> different meta-model which is a sub-set of the "master" meta-model.
> There is also an editor application that "knows" all.
>
Yet the generated model will have getters for these things and will need
features associated with those. And the generated XyzPackage interface
also has getters for the features. It just doesn't seem coherent.
>
>> Are you sure you shouldn't just be modifying the property descriptors to
>> selectively filter out certain properties or children depending on the
>> state of the instance?
>>
> Well - sorry, but I don't quite get what you mean by "property
> descriptors". How do I modify them?
>
Each generated item provider has a generated getPropertyDescriptors
method and you could filter what's in that list. You'd need to be
careful to recompute it for each instance rather than using the default
approach where the answer is computed once and cached.
> Possibly you are right, but in fact I'm trying to implement several
> (client) applications that are allowed to modify only parts of a
> "config" they are responsible for. The master application can then
> "import" all the different sub-configs to a global "master" one.
> Unfortunately the logic behind doesn't allow me to really split this up
> into several models. There are links between the sub-configs which need
> to be considered but these are partially read-only for the different
> "client application" instances.
>
It seems to me that each editor should just provide a filtered view that
shows only what's necessary. By filtering getPropertyDescriptors,
getchildrenFeatures, and collectNewChildDescriptors, you should be able
to provide a view that limits access to those things that should be visible.
> With regards, Morten.
>
--------------090806060705050707040009
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">
Morten,<br>
<br>
Comments below.<br>
<br>
Morten MacFly wrote:
<blockquote cite="mid:fhk1ok$g9o$1@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This part really confuses me. The visibility state is controlled per
instance but you are talking about change the metamodel itself which
affects all instances.
</pre>
</blockquote>
<pre wrap=""><!---->Yes! That's exactly what I want to achieve. This means that according to
what config I load on startup of the application all (!) editors use a
different meta-model which is a sub-set of the "master" meta-model.
There is also an editor application that "knows" all.
</pre>
</blockquote>
Yet the generated model will have getters for these things and will
need features associated with those. And the generated XyzPackage
interface also has getters for the features. It just doesn't seem
coherent.<br>
<blockquote cite="mid:fhk1ok$g9o$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Are you sure you shouldn't just be modifying the property descriptors to
selectively filter out certain properties or children depending on the
state of the instance?
</pre>
</blockquote>
<pre wrap=""><!---->Well - sorry, but I don't quite get what you mean by "property
descriptors". How do I modify them?
</pre>
</blockquote>
Each generated item provider has a generated getPropertyDescriptors
method and you could filter what's in that list. You'd need to be
careful to recompute it for each instance rather than using the default
approach where the answer is computed once and cached.<br>
<blockquote cite="mid:fhk1ok$g9o$1@build.eclipse.org" type="cite">
<pre wrap="">
Possibly you are right, but in fact I'm trying to implement several
(client) applications that are allowed to modify only parts of a
"config" they are responsible for. The master application can then
"import" all the different sub-configs to a global "master" one.
Unfortunately the logic behind doesn't allow me to really split this up
into several models. There are links between the sub-configs which need
to be considered but these are partially read-only for the different
"client application" instances.
</pre>
</blockquote>
It seems to me that each editor should just provide a filtered view
that shows only what's necessary. By filtering
getPropertyDescriptors, getchildrenFeatures, and
collectNewChildDescriptors, you should be able to provide a view that
limits access to those things that should be visible.<br>
<blockquote cite="mid:fhk1ok$g9o$1@build.eclipse.org" type="cite">
<pre wrap="">
With regards, Morten.
</pre>
</blockquote>
<br>
</body>
</html>
--------------090806060705050707040009--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Tue Apr 23 14:29:06 GMT 2024
Powered by FUDForum. Page generated in 0.03028 seconds |
] 
Search
Help
Register
Login
Home
