[news.eclipse.platform] Re: common navigator framework

["Henry Chow" <henkankun@xxxxxxxxxxx>]

Thanks Michael, I'll look into that.

"Michael Valenta" <Michael_Valenta@xxxxxxxxxx> wrote in message 
news:fi1hce$p84$1@xxxxxxxxxxxxxxxxxxxx
> Henry,
>
> It turns out that the Team Synchronize view uses the common navigator 
> framework. However, it does so at the viewer level instead of the view 
> part level. That is, the Synchronize view defines it's own view part but 
> uses a CommonViewer inside that. You may want to investigate whether this 
> option would work for you.
>
> Michael
>
> Henry Chow wrote:
>> Thank you for your prompt replies :)
>>  So, regarding the filtered tree.  I agree with you, but I'm just the 
>> engineer here ;).  I can push for a different approach towards filtering, 
>> but ultimately, it is not my decision to make, sadly.
>>  Regarding the updatePlus - we have certain parent tree items, that when 
>> expanded by the user, we need to prompt to connect to an external 
>> resource to retrieve the data.  So, we have added some logic into the 
>> updatePlus to make this work correctly.  I know this is vague, and 
>> perhaps not the best way to handle this situation.  Really, I mentioned 
>> this case only as an example of our need to subclass the treeviewer, in 
>> general, and extend it to suit our needs. Regarding reusability and 
>> intent - We have a set of applications that should share the same tree at 
>> runtime.  A lot of this work can be done through CNF (via the extension 
>> points for content and label providers, etc..).  All these applications 
>> require, though, that the tree provide certain services (such as the edit 
>> control for filtering, as one example), that is not provided by the 
>> existing CommonNavigator and can not be added through the existing CNF 
>> extension points.
>>  "Ed Merks" <merks@xxxxxxxxxx <mailto:merks@xxxxxxxxxx>> wrote in
>>     message news:fhvvq1$dgu$1@xxxxxxxxxxxxxxxxxxxx
>>     Henry,
>>
>>     Comments below.
>>
>>     Henry Chow wrote:
>>>     For example, to be able to add an edit control in the viewpart above 
>>> the tree so that the user can type in keywords and filter the tree based 
>>> on those keywords (i.e., the FilteredTree control).
>>>
>>     Wouldn't it be better to use a toolbar for that.  There is already a
>>     customize action in which to specify filters.
>>>     Other examples are to modify the behavior of the tree that comes 
>>> within the CommonNavigator - such as being able to extend the updatePlus 
>>> treeviewer method.
>>>
>>     To do what?
>>>     For the tree, I understand that the CommonViewer can be extended. 
>>> But if I create my own treeviewer by subclassing CommonViewer, I have no 
>>> view part with CNF supported services to place this tree in. ?
>>>
>>     Is this specialized navigator you are going to build intended to be
>>     reused by all projects running in the IDE the way the base one is
>>     intended to be used?  I'm sure the intent here is for everyone to
>>     share one implementation rather than for each application to create
>>     customized ones, but maybe that's not an issue for how you intend to
>>     use it...
>>>     "Ed Merks" <merks@xxxxxxxxxx> wrote in message 
>>> news:fhvp7n$8ol$2@xxxxxxxxxxxxxxxxxxxx
>>>
>>>>     Henry,
>>>>
>>>>     Typically when code says it should not be subclassed it's because 
>>>> they expect that everything can be accomplished by adding handlers and 
>>>> otherwise configuring the base implementation.  I think everyone 
>>>> generally expects to share the one basic implementation of the common 
>>>> navigator, so it would be odd for there to be another specialized one. 
>>>> Maybe it will help to know what you are trying to achieve.
>>>>
>>>>
>>>>     Henry Chow wrote:
>>>>
>>>>>     Hello,
>>>>>
>>>>>     First time newsgroup poster ;).  I had a question about the common 
>>>>> navigator framework.  There is a CommonNavigator viewpart that 
>>>>> provides all the basic CNF services.  This is almost perfect for me, 
>>>>> however, I need to add some additional custom GUI components to the 
>>>>> viewpart.  The problem is that the comments state that it is not 
>>>>> recommended to subclass CommonNavigator.  So, is there a viewpart 
>>>>> class that I can subclass that provides all the fundamental CNF 
>>>>> services?  I would hate to just simply "copy/paste" all the code from 
>>>>> CommonNavigator into my own viewpart simply because CommonNavigator 
>>>>> shouldn't be subclassed...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>