|
|
|
| Re: Applying constraints on CellEditor for EReference attributes [message #427914 is a reply to message #427913] |
Thu, 05 March 2009 14:19   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi,
>
> thanks a lot for the insight and want to tell you that developing with
> the EMF is quite a fun and does save us a lot of work.
>
> Although I couldn't find the
> EReferenceItemProvider.addEOppositePropertyDescriptor example I came
> to a solution.
I'll bet you don't use Ctrl-Shift-T a lot. You should!
>
> As I want to keep manually written code in one place and to be able to
> exchange/regenerate the edit/editor code I changed the
You know about @generated NOT and about renaming foo() to fooGen() I assume?
>
> add<%=genFeature.getCapName()%>PropertyDescriptor(Object object)
>
> method in the JET template for the item provider so that it now asks
> the model object if it provides an alternate item property descriptor
> and if so uses that one.
I see. That's an interesting approach. Though the logic ends up living
somewhere, so why not the item provider...
>
> For that to be possible I changed the model's root interface from
> EObject to MyEObject which provides the respective method prototype.
> Implemented that method so that it returns the alternate item property
> descriptor based on ItemPropertyDescriptorDecorator.
>
> One question that came up then was the meaning of the filterFlags
> String array. According to another news post it is currently only used
> to mark features as "expert" features so hiding features unless the
> user turns the properties view into "advanced" mode. Is the
> filterFlags intended to only control the visibility of the feature
Yes.
> in the properties view or should it be considered more of a multi
> purpose attribute which can for example also be used to configure how
> a feature can be displayed or modified?
Not so much.
>
> Regards,
> Dirk
>
>
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> we are building a tool that allows one to formulate a query based on
>>> a data model (=schema).
>>>
>>> We therefore call it "schema based query". The Ecore meta model
>>> essentially looks like this:
>>>
>>> +----------------+
>>> |SchemaBasedQuery|
>>> +----------------+
>>> | |
>>> | | contains
>>> | | +------+
>>> | `--> |Schema|
>>> | 1..1 +------+
>>> | |
>>> | | contains
>>> | | +------------+
>>> | `--> |Type |
>>> | 0..* +------------+
>>> | |String: name|
>>> | +------------+
>>> | ^ |
>>> | | 1..1 | contains
>>> | | | +------------+
>>> | | `--> |Attribute |
>>> | | 0..* +------------+
>>> | | |String: name|
>>> | | +------------+
>>> | contains | ^
>>> | +-----+ | basedOnType |
>>> `--> |Query| | (association) | 1..1
>>> 0..* +-----+ | |
>>> | | |
>>> | contains | |
>>> | +-----------+ |
>>> `--> |TypeToQuery| | basedOnAttribute
>>> 0..* +-----------+ | (association)
>>> | |
>>> | contains |
>>> | +----------------+ |
>>> `--> |AttributeToQuery| --´
>>> 0..* +----------------+
>>>
>>>
>>> So there is a "Schema" branch with "Type" and "Attribute" elements
>>> and a branch of Queries containing "TypeToQuery" and
>>> "AttributeToQuery" elements which refer to "Type" resp. "Attribute"
>>> elements in the "Schema" branch.
>>>
>>> We started of with the generated tree-editor.
>>>
>>> Now the problem we are faced with:
>>> When editing the "basedOnAttribute" association in the Properties
>>> view of the generated editor the drop-down-menu lists all Attributes
>>> of all Types contained in the Schema part. What we want to see
>>> instead is a list of only the Attributes of the Type the TypeToQuery
>>> container refers to with its "basedOnType" association.
>>>
>>> Does anyone have an idea how to achieve this?
>> Specialize the property descriptor to filter what's available in the
>> getChoiceOfValues. See
>> EReferenceItemProvider.addEOppositePropertyDescriptor for an
>> example. Here the opposite reference must be in the reference's type
>> and must of of the correct type.
>>>
>>> Are constraints (maybe as OCL) an answer to this problem or can
>>> they only be used to validate the model instance after editing?
>> Mostly it helps with after the fact mistakes.
>>>
>>> Which is the best place for our custom code?
>> The item provider.
>>>
>>> Change the generated editor class's getPropertySheetPage() method?
>> Nope, you should always be able to get by specializing the item
>> property descriptor in the item provider or at worse, specialize the
>> PropertyDescriptor that's created to wrap them (if you need to create
>> a specialized type of cell editor).
>>>
>>> Looking forward to your ideas.
>>>
>>> Regards,
>>> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
| Re: Applying constraints on CellEditor for EReference attributes [message #427935 is a reply to message #427922] |
Fri, 06 March 2009 11:20 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Dirk,
When I want to debug the generator I start a second Eclipse workbench
under debug control...
Dirk Hoffmann wrote:
> See below.
>
> Ed Merks schrieb:
>> Dirk,
>>
>> I'm not sure I follow. You can set breakpoints in the compiled
>> template. It's a little hard to read though...
> Yes but how do I get it to run in debug mode?
>>
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> another qustion that came up is how to debug the jet-generator
>>> (using EMF 2.2.5 with Callisto).
>>>
>>> I know there's been a post on this before but I didn't understand
>>> Ed's explanations.
>>>
>>> Regards Dirk
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Dirk,
>>>>
>>>> Comments below.
>>>>
>>>> Dirk Hoffmann wrote:
>>>>> Hi,
>>>>>
>>>>> we are building a tool that allows one to formulate a query based
>>>>> on a data model (=schema).
>>>>>
>>>>> We therefore call it "schema based query". The Ecore meta model
>>>>> essentially looks like this:
>>>>>
>>>>> +----------------+
>>>>> |SchemaBasedQuery|
>>>>> +----------------+
>>>>> | |
>>>>> | | contains
>>>>> | | +------+
>>>>> | `--> |Schema|
>>>>> | 1..1 +------+
>>>>> | |
>>>>> | | contains
>>>>> | | +------------+
>>>>> | `--> |Type |
>>>>> | 0..* +------------+
>>>>> | |String: name|
>>>>> | +------------+
>>>>> | ^ |
>>>>> | | 1..1 | contains
>>>>> | | | +------------+
>>>>> | | `--> |Attribute |
>>>>> | | 0..* +------------+
>>>>> | | |String: name|
>>>>> | | +------------+
>>>>> | contains | ^
>>>>> | +-----+ | basedOnType |
>>>>> `--> |Query| | (association) | 1..1
>>>>> 0..* +-----+ | |
>>>>> | | |
>>>>> | contains | |
>>>>> | +-----------+ |
>>>>> `--> |TypeToQuery| | basedOnAttribute
>>>>> 0..* +-----------+ | (association)
>>>>> | |
>>>>> | contains |
>>>>> | +----------------+ |
>>>>> `--> |AttributeToQuery| --´
>>>>> 0..* +----------------+
>>>>>
>>>>>
>>>>> So there is a "Schema" branch with "Type" and "Attribute" elements
>>>>> and a branch of Queries containing "TypeToQuery" and
>>>>> "AttributeToQuery" elements which refer to "Type" resp.
>>>>> "Attribute" elements in the "Schema" branch.
>>>>>
>>>>> We started of with the generated tree-editor.
>>>>>
>>>>> Now the problem we are faced with:
>>>>> When editing the "basedOnAttribute" association in the Properties
>>>>> view of the generated editor the drop-down-menu lists all
>>>>> Attributes of all Types contained in the Schema part. What we want
>>>>> to see instead is a list of only the Attributes of the Type the
>>>>> TypeToQuery container refers to with its "basedOnType" association.
>>>>>
>>>>> Does anyone have an idea how to achieve this?
>>>> Specialize the property descriptor to filter what's available in
>>>> the getChoiceOfValues. See
>>>> EReferenceItemProvider.addEOppositePropertyDescriptor for an
>>>> example. Here the opposite reference must be in the reference's
>>>> type and must of of the correct type.
>>>>>
>>>>> Are constraints (maybe as OCL) an answer to this problem or can
>>>>> they only be used to validate the model instance after editing?
>>>> Mostly it helps with after the fact mistakes.
>>>>>
>>>>> Which is the best place for our custom code?
>>>> The item provider.
>>>>>
>>>>> Change the generated editor class's getPropertySheetPage() method?
>>>> Nope, you should always be able to get by specializing the item
>>>> property descriptor in the item provider or at worse, specialize
>>>> the PropertyDescriptor that's created to wrap them (if you need to
>>>> create a specialized type of cell editor).
>>>>>
>>>>> Looking forward to your ideas.
>>>>>
>>>>> Regards,
>>>>> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04366 seconds
] 
Search
Help
Register
Login
Home
