Re: [platform-ui-dev] [CN] Updates for the Common Navigator in Platform

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Nick,

The core.resources plugin now has a
dependency on the expressions plugin. It was added to allow the ModelProvider
to use expressions to match resources of interest. I think it makes sense
to have the resource based expressions there as well, especially considering
that ModelProvider implementors will want to use them for their matching
rules.

Michael

Nick Edgar/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

29/11/2005 09:52 AM

Please respond to
"Eclipse Platform UI component developers list."

To	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-ui-dev] [CN] Updates for the Common        Navigator        in        Platform        3.2

Dirk,

There are not currently any property testers at org.eclipse.core.resources
level.  There are some rudimentary ones at org.eclipse.ui.ide level,
but I 
was going to provide a fully featured one to support the Common Navigator
and other scenarios.  It should be at least as expressive as the 
IActionFilter for resources.
While it would be better to put this in core.resources, core.resources
does not currently depend on core.expressions.  Let me check with
the core 
team to see how they feel about this.

Nick




Michael Elder <mdelder@xxxxxxxxxx> 
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
11/29/2005 09:35 AM
Please respond to
"Eclipse Platform UI component developers list."


To
"Eclipse Platform UI component developers list." 
<platform-ui-dev@xxxxxxxxxxx>
cc
platform-ui-dev@xxxxxxxxxxx, platform-ui-dev-bounces@xxxxxxxxxxx
Subject
Re: [platform-ui-dev] [CN] Updates for the Common Navigator    
in 
Platform        3.2








Hi Dirk,

      Your first point was my oversight. It wasn't apparent
to me in the
documentation that enclosing the test element in adapt was required. When
following through the _expression_ in the debugger, it tested both 
properties
in series (adapts to IProject, then IProject.hasNature()). The use of
"args" instead of value can also be corrected. When looking for
documentation on the test element, I didn't see that it had a value
attribute.

      The property tester is in a lone plugin in my workspace.
Nick has
proposed that I release this property tester as part of
org.eclipse.ui.navigator.resources; at which point, the namespace will
change to match the plugin. I'll release this today and send out a new
version of the JDT patch with the changes that you have suggested.

      Thanks!


-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / Services Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx




Tuesday, November 29, 2005 4:45 AM
To: "Eclipse Platform UI component developers list."
<platform-ui-dev@xxxxxxxxxxx>
cc: platform-ui-dev@xxxxxxxxxxx, platform-ui-dev-bounces@xxxxxxxxxxx
From: Dirk Baeumer <dirk_baeumer@xxxxxxxxxx>
Subject: Re: [platform-ui-dev] [CN] Updates for the Common Navigator in
Platform    3.2



Hi Michael,

here some feedback to the use of the _expression_ language:

<and>
<adapt type="org.eclipse.core.resources.IProject" />
<test property="org.eclipse.core.resources.projectNature"
         args="org.eclipse.jdt.core.javanature"
/>
         </and>

The current <adapt> _expression_ is superfluous since the element adapted
to
IProject is only
visible inside of the adapt element. So the _expression_ should either look
like:

<and>
<adapt type="org.eclipse.core.resources.IProject">
       <test property="org.eclipse.core.resources.projectNature"
       args="org.eclipse.jdt.core.javanature"
/>
   </adapt>
   </and>

or the adapt _expression_ can be removed assuming that the default variable
(or an
explicit provided variable) used is always of type IResource/IProject
(depending
on how the project nature tester is implemented)

Furthermore the test _expression_ looks strange to me as well. IMO it should
be

       <test property="org.eclipse.core.resources.projectNature"
       value="org.eclipse.jdt.core.javanature"
/>

since you are expecting the nature value to be
org.eclipse.jdt.core.javanature
or the property name should be hasNature. I prefer the former.

And a more general question: which plug-in contains the implementation
of
the
nature tester. If it is not the core resource plug-in (which I would 
prefer
to be) then
the name space should not be org.eclipse.core.resources. The namespace
should always match the plug-in providing the tester.

Nick, is there any activity going on to provide resource specific property
testers
in the core resources plug-in ?

Dirk



             Michael Elder
             <mdelder@xxxxxx.c
             om>      
                     
                     
     To
             Sent by:      
           platform-ui-dev@xxxxxxxxxxx
             platform-ui-dev-b    
                     
               cc
             ounces@xxxxxxxxxx
             g        
                     
                     
Subject
                    
                  [platform-ui-dev]
[CN] Updates for
                    
                  the Common
Navigator in Platform
             28/11/2005 03:34    
     3.2
             AM


             Please respond to
             "Eclipse Platform
               UI component
               developers list."
               <platform-ui-dev@
               eclipse.org>







Changes have been made to the Common Navigator which require changes for
early adopters. The following 5 items will require some reaction from 
early
adopters.



(1)        Expressions converted to org.eclipse.core.expressions.

Old:
<objectClass name="org.eclipse.core.resources.IWorkspaceRoot"
/>


New:
<instanceof value="org.eclipse.core.resources.IFile" />



Old:
<objectClass name="org.eclipse.core.resources.IWorkspaceRoot"
             adapt=?true? />


New:
<adapt type="org.eclipse.core.resources.IWorkspaceRoot" />



Old:
<and>
   <objectClass name="org.eclipse.core.resources.IProject"
   adapt=?true? />
   <objectState name="nature"
   value="org.eclipse.jdt.core.javanature" />
</and>


New:
<and>
   <adapt type="org.eclipse.core.resources.IProject"
/>
   <test property="org.eclipse.core.resources.projectNature"
         args="org.eclipse.jdt.core.javanature"
/>
         </and>


(2)        ?enablement? split into two more focused
expressions:
?triggerPoints? and ?possibleChildren? ? see schema doc for
navigatorContent.
(3)        navigatorViewer renamed to viewerContentBinding
? see schema 
doc
for viewerContentBinding. Also, the rootContentExtensionId attribute has
also been reformed as part of the enhanced viewer configuration. Clients
may now specify regular expressions to describe the content extensions
that
should be included or excluded.

Old:
<navigatorViewer
   rootContentExtensionId="org.eclipse.core.resources.resourceContent"
   viewerId="org.eclipse.core.resources.resourceViewer"
 />


New:        <viewerContentBinding
viewerId=?org.eclipse.core.resources.resourceViewer?>

   <includes>
   <contentExtension
         pattern="org.eclipse.core.resources.resourceContent"
         isRoot=?true? />
   </includes>
   </viewerContentBinding>


(4)        The popup menu id of ?viewerContentBinding?
now defaults to the
viewer id, but can be overridden in the viewerContentBinding extension
point (formerly navigatorViewer).

(5)        Each extension has three states that are
relevant. For
consistency, the following terms have specific meanings:
visible: A content extension is visible if the set of aggregated includes
and excludes statements for all viewerContentBindings allow the extension
to be invoked by a viewer.
active: A content extension is active if the user has not disabled the
content extension in the ?Available types of content? dialog and/or the
enabledByDefault attribute of the navigatorContent extension allows the
content extension to be ?active?
enabled: A content extension is enabled for a specific element only if
it
contributed the element to the viewer or the element matches its
triggerPoints _expression_ in the navigatorContent extension point.


The full change log for the release:

Resolving several defects [..]
+ 117591 [CommonNavigator] References to the AWT and Swing libraries 
should
be removed
+ 116690 [CommonNavigator] View title is blank
+ 114993 [CommonNavigator] Missing NLS message
+ 116685 [CommonNavigator] ClassCastException trying to execute action
+ 115130 [CommonNavigator] Port the ActionExpression enablement classes
to
org.eclipse.core.expressions

_______________________________________________________________________________

+ 116460 [CommonNavigator] Code review comments

The following issues from the review have been addressed.


General issues
==============

Illegal internal refs:
- Should use org.eclipse.core.expressions, not old action filter
expressions and
IActionFilter (ActionExpression is internal to UI, not API).  It's
more
flexible
and extensible, and it's API.
- WorkbenchMessages -  Copy strings if necessary.
- WorkbenchPlugin - Registries are available via API on IWorkbench (or
should be).
- IWorkbenchHelpContextIds - Need to decide whether CN should define its
own
help ids here, or whether we need to expose some Workbench ones as API.
- Assert - Use the one in JFace.

Fix up copyright header in .java files (e.g. copy from IWorkbench,
adjusting
dates accordingly).

Fix up deprecations:
- WorkbenchHelp -> IWorkbench.getHelpSystem

Legal:
- All plug-ins should have about.html.  Can copy from org.eclipse.ui.
Important: if any content did not come directly from us this needs to be
raised
and reviewed before we can put it under the EPL.

NLS: Need to externalize all human-readable strings in code and plug-in
manifests (except for log messages).  Ensure the corresponding JDT
and PDE
compiler settings generate errors.  Use project-specific settings,
and
ensure
they're shared in CVS (e.g. copy the settings from
org.eclipse.ui.workbench).
Mark strings that should not be externalized with  //$NON-NLS-#$.
Ctrl+1 
is
your
friend for these.  Note: Job names do show up in the UI, in the Progress
indicator and view, and should be externalized.
...
Extension points:
...
    - class attributes should be of Kind "java" with
type name specified 
in

Based On property
...
@since tags:
- Need @since 3.2 tags on all API types.

Build.properties file:
- ensure it is accurate for all projects
- proper source folders for jars (top pane)
- proper files and folders for source and binary builds (excluding source

folders in top pane)
- binary build must have: plugin.xml, plugin.properties, META-INF dir,
and
any icon dirs
    - source build must include xpt schemas
    ...
    - property_files/messages.properties
  - is this used (in addition to navigator_messages.properties?)

_____________________________________________________________________

+115486        [CommonNavigator] [arch] Navigator viewers
should be more
configurable
The former "navigatorViewer" extension point has been renamed
to
"viewerContentBinding".
The new extension point defines two elements 'includes' and 'excludes'
which can describe (using regular expressions) which content extensions
should be visible to the viewer with the given viewer id. This extension
point augments one existing org.eclipse.ui.views extension and potentially
multiple org.eclipse.ui.navigator.navigatorContent extensions.
______________________________________________________________________
+114931 [CommonNavigator] Filtering by types of content shws all content
types
As part of 115486, the "Filter by types of content" dialog now
only shows
extensions which are described by one or more
org.eclipse.ui.navigator.viewerContentBinding extensions.
_______________________________________________________________________
+ 114940 [CommonNavigator] [Discussion] Navigator extensions only operate
at one level
Extensions now automatically are given the opportunity to contribute
children to elements they have already contributed.
_______________________________________________________________________
+ 115123 [CommonNavigator] [API] Update extension point schema doc for
navigatorContent
The extension point schema has been further update. This defect will be
closed for now, but please provide feedback and re-open if there are
still areas that need clarification.

_______________________________________________________________________
+ 118170 [CommonNavigator] [Resource] Support Open/Open With menu
extensions
Added open/open with menu and retargetable action with actionId
ICommonMenuConstants.OPEN.
_______________________________________________________________________
+ 117065 [CommonNavigator] Should support better filtering of duplicate
content
Extensions may now define filters with their extension which are
not known to the user, and are active only when the content extension is
'active'.
-------------------------------------------------------------------------

The attached patch is for the working version of the Java extension. No
changes have been addressed yet from the code review from Dirk (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=116460) , but these are on
there way. This patch is for clients that are experimenting with the Java
extension in their environments.



For clients that are interested in the override discussion, I think the
final conclusion is that the ability to override specific extensions for
navigatorContent and actionProvider will be required. That will be next
delivery of functoinality for the Common Navigator framework. In addition,
a 'depends' attribute may allow more relative prioritizing of extensions
instead of the generic (Lowest ... Highest) scale.

For clients that are anxiously anticipating other feature enhancements,
thank you for your patience as we stablize the API and base framework
through the M4 milestone. Other more 'feature' type enhancements will be
addressed in M5.


Kind Regards,

Michael D. Elder
Rational Studio / Services Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx
(See attached file: org.eclipse.jdt.ui_patch.txt)
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
(See attached file: org.eclipse.jdt.ui_patch.txt)
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

(Attachments removed)_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev


_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev