Home » Modeling » EMF » ViewerFilter and EMF
| |
| Re: ViewerFilter and EMF [message #513628 is a reply to message #513602] |
Wed, 10 February 2010 12:48   |
 Martin Tauber
Messages: 122
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
just to confirm, (Because I got confused about this in one of our last
conversations) I'd add something like this to my code:
class ViewContentProvider extends AdapterFactoryContentProvider {
public ViewContentProvider(AdapterFactory adapterFactory) {
super(adapterFactory);
}
getChildren(...) {
if (parent instanceof bla) {
return parent.getPathOneChildren();
} else if (parent instanceof blubber) {
return parent.getPathTwoChildren();
}
return super.getChildren(parent);
}
....
}
Am 10.02.10 17:40, schrieb Ed Merks:
> Martin,
>
> Comments below.
>
> Martin Tauber wrote:
>> I have some questions concerning views:
>>
>> I want to create different views on my model. basically there is
>> somethink like the "container" view, which lists the objects how they
>> are stored in the files and there is a hierachy view which shows the
>> relation hierachy of the objects. I was thinking about using the
>> emf.edit children property to enable the emf code genertor to build
>> ContentProviders which will for the same model object deliver both
>> paths and then use ViewerFilters in the different views to filter out
>> the path witch in that view is not of interest.
>>
>> Now here are my questions:
>>
>> 1) Is this the recommanded way to go?
> Not really.
>>
>> 2) Ok I already when down this path and ran into bug 203950 where the
>> (+) sign now is shown in the treeview, even though the filter has
>> filtered all children of the object. I read that there is a plan to
>> somehow make this behaiviour configurable within emf. Is that
>> implemented and if yes what do I need to do?
> The filter stuff is beyond EMF's control. The platform would need to be
> a bit less lazy about determining if this + should appear, i.e., call
> getChildren, apply the filter and test if anything is left. Of course
> that's more expensive than calling hasChildren...
>
> For your purpose I think it's better to define a basic view with the
> generated item providers and then specialize those to produce the other
> views. This is similar to what we do with
> XSDSemanticItemProviderAdapterFactory to provide a logical view rather
> than the more basic concrete view.
>>
>> Regards
>> Martin
|
|
|
| Re: ViewerFilter and EMF [message #513636 is a reply to message #513628] |
Wed, 10 February 2010 17:55 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
Martin Tauber wrote:
> Hi Ed,
>
> just to confirm, (Because I got confused about this in one of our last
> conversations) I'd add something like this to my code:
>
> class ViewContentProvider extends AdapterFactoryContentProvider {
> public ViewContentProvider(AdapterFactory adapterFactory) {
> super(adapterFactory);
> }
>
> getChildren(...) {
> if (parent instanceof bla) {
> return parent.getPathOneChildren();
>
> } else if (parent instanceof blubber) {
> return parent.getPathTwoChildren();
>
> }
>
> return super.getChildren(parent);
> }
> ...
> }
No. I'd expect you to specialize XyzItemProviderAdapterFactory and use
that to create specialized AbcItemProvider instances with specialized
getChildren methods or more likely specializing the
getChildrenFeatures. Look at XSDSemanticItemProviderAdapterFactory as
an example.
>
> Am 10.02.10 17:40, schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>> Martin Tauber wrote:
>>> I have some questions concerning views:
>>>
>>> I want to create different views on my model. basically there is
>>> somethink like the "container" view, which lists the objects how they
>>> are stored in the files and there is a hierachy view which shows the
>>> relation hierachy of the objects. I was thinking about using the
>>> emf.edit children property to enable the emf code genertor to build
>>> ContentProviders which will for the same model object deliver both
>>> paths and then use ViewerFilters in the different views to filter out
>>> the path witch in that view is not of interest.
>>>
>>> Now here are my questions:
>>>
>>> 1) Is this the recommanded way to go?
>> Not really.
>>>
>>> 2) Ok I already when down this path and ran into bug 203950 where the
>>> (+) sign now is shown in the treeview, even though the filter has
>>> filtered all children of the object. I read that there is a plan to
>>> somehow make this behaiviour configurable within emf. Is that
>>> implemented and if yes what do I need to do?
>> The filter stuff is beyond EMF's control. The platform would need to be
>> a bit less lazy about determining if this + should appear, i.e., call
>> getChildren, apply the filter and test if anything is left. Of course
>> that's more expensive than calling hasChildren...
>>
>> For your purpose I think it's better to define a basic view with the
>> generated item providers and then specialize those to produce the other
>> views. This is similar to what we do with
>> XSDSemanticItemProviderAdapterFactory to provide a logical view rather
>> than the more basic concrete view.
>>>
>>> Regards
>>> Martin
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ViewerFilter and EMF [message #513687 is a reply to message #513636] |
Wed, 10 February 2010 14:56 |
Martin Tauber
Messages: 122
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
do I have to access the CVS repository to look at the code (and install
the cvs plugin ... :-( (I have been searching until the end of the
internet to find it online ...
Am 10.02.10 18:55, schrieb Ed Merks:
> Martin,
>
> Comments below.
>
>
> Martin Tauber wrote:
>> Hi Ed,
>>
>> just to confirm, (Because I got confused about this in one of our last
>> conversations) I'd add something like this to my code:
>>
>> class ViewContentProvider extends AdapterFactoryContentProvider {
>> public ViewContentProvider(AdapterFactory adapterFactory) {
>> super(adapterFactory);
>> }
>>
>> getChildren(...) {
>> if (parent instanceof bla) {
>> return parent.getPathOneChildren();
>>
>> } else if (parent instanceof blubber) {
>> return parent.getPathTwoChildren();
>>
>> }
>>
>> return super.getChildren(parent);
>> }
>> ...
>> }
> No. I'd expect you to specialize XyzItemProviderAdapterFactory and use
> that to create specialized AbcItemProvider instances with specialized
> getChildren methods or more likely specializing the getChildrenFeatures.
> Look at XSDSemanticItemProviderAdapterFactory as an example.
>>
>> Am 10.02.10 17:40, schrieb Ed Merks:
>>> Martin,
>>>
>>> Comments below.
>>>
>>> Martin Tauber wrote:
>>>> I have some questions concerning views:
>>>>
>>>> I want to create different views on my model. basically there is
>>>> somethink like the "container" view, which lists the objects how they
>>>> are stored in the files and there is a hierachy view which shows the
>>>> relation hierachy of the objects. I was thinking about using the
>>>> emf.edit children property to enable the emf code genertor to build
>>>> ContentProviders which will for the same model object deliver both
>>>> paths and then use ViewerFilters in the different views to filter out
>>>> the path witch in that view is not of interest.
>>>>
>>>> Now here are my questions:
>>>>
>>>> 1) Is this the recommanded way to go?
>>> Not really.
>>>>
>>>> 2) Ok I already when down this path and ran into bug 203950 where the
>>>> (+) sign now is shown in the treeview, even though the filter has
>>>> filtered all children of the object. I read that there is a plan to
>>>> somehow make this behaiviour configurable within emf. Is that
>>>> implemented and if yes what do I need to do?
>>> The filter stuff is beyond EMF's control. The platform would need to be
>>> a bit less lazy about determining if this + should appear, i.e., call
>>> getChildren, apply the filter and test if anything is left. Of course
>>> that's more expensive than calling hasChildren...
>>>
>>> For your purpose I think it's better to define a basic view with the
>>> generated item providers and then specialize those to produce the other
>>> views. This is similar to what we do with
>>> XSDSemanticItemProviderAdapterFactory to provide a logical view rather
>>> than the more basic concrete view.
>>>>
>>>> Regards
>>>> Martin
>>
|
|
|
| Re: ViewerFilter and EMF [message #513698 is a reply to message #513687] |
Wed, 10 February 2010 20:59 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Martin,
If you have the SDK installed, then you already have the source.
Ctrl-Shift-T should find it. If it's not showing up (because you have
no plug-in dependencies on it) go to the PDE's Plug-ins view, select
them all, and invoke "Add to Java Search" from the context menu.
Martin Tauber wrote:
> Hi Ed,
>
> do I have to access the CVS repository to look at the code (and
> install the cvs plugin ... :-( (I have been searching until the end of
> the internet to find it online ...
>
>
> Am 10.02.10 18:55, schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Tauber wrote:
>>> Hi Ed,
>>>
>>> just to confirm, (Because I got confused about this in one of our last
>>> conversations) I'd add something like this to my code:
>>>
>>> class ViewContentProvider extends AdapterFactoryContentProvider {
>>> public ViewContentProvider(AdapterFactory adapterFactory) {
>>> super(adapterFactory);
>>> }
>>>
>>> getChildren(...) {
>>> if (parent instanceof bla) {
>>> return parent.getPathOneChildren();
>>>
>>> } else if (parent instanceof blubber) {
>>> return parent.getPathTwoChildren();
>>>
>>> }
>>>
>>> return super.getChildren(parent);
>>> }
>>> ...
>>> }
>> No. I'd expect you to specialize XyzItemProviderAdapterFactory and use
>> that to create specialized AbcItemProvider instances with specialized
>> getChildren methods or more likely specializing the getChildrenFeatures.
>> Look at XSDSemanticItemProviderAdapterFactory as an example.
>>>
>>> Am 10.02.10 17:40, schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>> Martin Tauber wrote:
>>>>> I have some questions concerning views:
>>>>>
>>>>> I want to create different views on my model. basically there is
>>>>> somethink like the "container" view, which lists the objects how they
>>>>> are stored in the files and there is a hierachy view which shows the
>>>>> relation hierachy of the objects. I was thinking about using the
>>>>> emf.edit children property to enable the emf code genertor to build
>>>>> ContentProviders which will for the same model object deliver both
>>>>> paths and then use ViewerFilters in the different views to filter out
>>>>> the path witch in that view is not of interest.
>>>>>
>>>>> Now here are my questions:
>>>>>
>>>>> 1) Is this the recommanded way to go?
>>>> Not really.
>>>>>
>>>>> 2) Ok I already when down this path and ran into bug 203950 where the
>>>>> (+) sign now is shown in the treeview, even though the filter has
>>>>> filtered all children of the object. I read that there is a plan to
>>>>> somehow make this behaiviour configurable within emf. Is that
>>>>> implemented and if yes what do I need to do?
>>>> The filter stuff is beyond EMF's control. The platform would need
>>>> to be
>>>> a bit less lazy about determining if this + should appear, i.e., call
>>>> getChildren, apply the filter and test if anything is left. Of course
>>>> that's more expensive than calling hasChildren...
>>>>
>>>> For your purpose I think it's better to define a basic view with the
>>>> generated item providers and then specialize those to produce the
>>>> other
>>>> views. This is similar to what we do with
>>>> XSDSemanticItemProviderAdapterFactory to provide a logical view rather
>>>> than the more basic concrete view.
>>>>>
>>>>> Regards
>>>>> Martin
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ViewerFilter and EMF [message #513699 is a reply to message #513687] |
Wed, 10 February 2010 21:08 |
Martin Tauber
Messages: 122
Registered: July 2009 |
Senior Member |
|
|
Hurray :-) I made it without the code :-) This is why I love to program,
you always get your little suceess feelings ;-)
Am 10.02.10 20:36, schrieb Martin Tauber:
> Hi Ed,
>
> do I have to access the CVS repository to look at the code (and install
> the cvs plugin ... :-( (I have been searching until the end of the
> internet to find it online ...
>
>
> Am 10.02.10 18:55, schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Tauber wrote:
>>> Hi Ed,
>>>
>>> just to confirm, (Because I got confused about this in one of our last
>>> conversations) I'd add something like this to my code:
>>>
>>> class ViewContentProvider extends AdapterFactoryContentProvider {
>>> public ViewContentProvider(AdapterFactory adapterFactory) {
>>> super(adapterFactory);
>>> }
>>>
>>> getChildren(...) {
>>> if (parent instanceof bla) {
>>> return parent.getPathOneChildren();
>>>
>>> } else if (parent instanceof blubber) {
>>> return parent.getPathTwoChildren();
>>>
>>> }
>>>
>>> return super.getChildren(parent);
>>> }
>>> ...
>>> }
>> No. I'd expect you to specialize XyzItemProviderAdapterFactory and use
>> that to create specialized AbcItemProvider instances with specialized
>> getChildren methods or more likely specializing the getChildrenFeatures.
>> Look at XSDSemanticItemProviderAdapterFactory as an example.
>>>
>>> Am 10.02.10 17:40, schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>> Martin Tauber wrote:
>>>>> I have some questions concerning views:
>>>>>
>>>>> I want to create different views on my model. basically there is
>>>>> somethink like the "container" view, which lists the objects how they
>>>>> are stored in the files and there is a hierachy view which shows the
>>>>> relation hierachy of the objects. I was thinking about using the
>>>>> emf.edit children property to enable the emf code genertor to build
>>>>> ContentProviders which will for the same model object deliver both
>>>>> paths and then use ViewerFilters in the different views to filter out
>>>>> the path witch in that view is not of interest.
>>>>>
>>>>> Now here are my questions:
>>>>>
>>>>> 1) Is this the recommanded way to go?
>>>> Not really.
>>>>>
>>>>> 2) Ok I already when down this path and ran into bug 203950 where the
>>>>> (+) sign now is shown in the treeview, even though the filter has
>>>>> filtered all children of the object. I read that there is a plan to
>>>>> somehow make this behaiviour configurable within emf. Is that
>>>>> implemented and if yes what do I need to do?
>>>> The filter stuff is beyond EMF's control. The platform would need to be
>>>> a bit less lazy about determining if this + should appear, i.e., call
>>>> getChildren, apply the filter and test if anything is left. Of course
>>>> that's more expensive than calling hasChildren...
>>>>
>>>> For your purpose I think it's better to define a basic view with the
>>>> generated item providers and then specialize those to produce the other
>>>> views. This is similar to what we do with
>>>> XSDSemanticItemProviderAdapterFactory to provide a logical view rather
>>>> than the more basic concrete view.
>>>>>
>>>>> Regards
>>>>> Martin
>>>
>
|
|
|
Goto Forum:
Current Time: Tue Sep 24 23:43:12 GMT 2024
Powered by FUDForum. Page generated in 0.03589 seconds |
] 
Search
Help
Register
Login
Home
