FixedLayerView

Revision as of 19:05, 13 December 2009 by Rmichalsky (Talk | contribs)

Working draft, part of PlatformPoolOfRcpTopics planning.

Use Cases, Requirements

  1. have a big picture view of "extension points" and service providers in the platform / RCP app
  2. provide contextual documentation for #1 directly available in IDE
  3. add new "extension point" and/or service provider for it
  4. locate/edit service provider module / class
  5. locate/edit module processing SP's for given extension point
  6. work with annotation-based registrations as well as layer based ones

Currently This layer in context node editor doesn't support #2, #5 and #6 at all and locating service provider class is clumsy.

On the other hand most of the use cases/requirements are already available for annotation-based regs. with Search, Find Usages and javadoc (as Jesse has already pointed out several times), except for perhaps #1. Notably it allows to locate consumer of the extension point (#5), as it is usually the module that declares the annotation. This is basically unsolvable for XML layers.

Conclusion

For preceeding discussion see [#Possible Solutions] below.

This layer in context node editor cannot be dropped in near future. The main reason is that the 3-rd group of layer paths (see discussion below) - used by RCP developers but not planned to be annotation-registered - is much bigger than originally thought, there is e.g.:

  • javahelp
  • component palette
  • file type integration

and others.

In order to retain current This layer in context behavior and fix the deficiencies, new Layer editor is proposed. It should have the following features:

  • to be continued

Possible Solutions

The easiest solution would be to let user edit important UI-related categories in separate branding editor (and not introduce annotations for them), add new annotations for entries that don't have one yet and are not important enough for dedicated editor and get rid of This layer and This layer in context nodes altogether. Special simple view for finding all annotations registering layer entries could be added to implement #1.

Alternative straightforward solution would be to somehow merge current layer view with annotations, e.g. by letting CoS create generated layers and use them. However there are several difficulties:

  • navigation from generated layer entry to the originating annotation would be hard or even impossible (but see below)
  • editing entries in UI would require automatic generation/editing of Java code or very different handling of XML and annotation-based entries

Or we could have a r/o view of the SFS for a suite project generated on demand (because it could take some time to process), say in the Output Window. Hyperlink every entry to the original layer.xml or annotation.

As to navigation from a layer entry to annotation: after cc1f043669a6 (in 6.9), there is now a comment associated with every generated layer entry (files and even some folders). If you can find the generated layer being merged (generally easy enough to do), just parse it to find the right file or folder element, look for a comment, and parse that comment to find a package name, class FQN, method name, etc.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo