FixedLayerView

(Redirected from FixedLayerView69)

Contents

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. locate/edit service provider module / class
  4. locate/edit module processing SP's for given extension point
  5. work with annotation-based registrations as well as layer based ones

Currently This layer in context node editor supports #1 well, doesn't support #2, #4 and #5 at all and #3 is clumsy.

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

Conclusion

For preceding discussion see #Possible Solutions below.

This layer in context node editor cannot be dropped without a replacement: there are many kinds of layer entries interpreted by the current Platform & IDE, and some may not lend themselves to natural expression as annotations.

Also branding entries will always be written as XML entries, even for layer paths usually registered by annotations.

In order to retain current This layer in context behavior and fix the deficiencies, new editor of layer.xml files - Layer editor - is proposed.

Layer Editor

It should have the following features:

  • shows up in editor area for convenience
  • offers several tabs with custom editors of various parts of the layer file (similar to e.g. web.xml editor in NB web project)
    • three always present tabs will be explorer views of current layer and layer in context, 3rd view will be plain XML editor.
      • if offered from a suite, first and third tabs make no sense
      • see below about "in context" distinction
    • other editor tabs, like ImprovedBrandingSupport69 or e.g. services (former META-INF/services) can be plugged in
  • code for current project nodes must be discarded (not reliable enough)
  • editor will NOT show live data, there will be manual Refresh button. This should improve performance and allow for easier integration of annotation-based registrations - see below
  • should also support drag&drop reordering for branding (lower priority)

New SPI should be added to allow modules to declare which layer paths they consume and to publish Javadoc URL for them.

Toolbar for layer in context tab:

  • Refresh
  • Filter annotation-based regs. (optionally only different icon & text)
  • Filter _hidden entries
  • Optionally layer and layer in context will not be separate tabs, but another filtering option
    • may also want richer options: all modules in app, all modules in cluster, all modules in transitive dependency tree, etc.

Context menu in layer in context tab:

  • Go to Declaration - works also for annotations (implemented in 6.9+1 dev)
  • New -> Folder - as usual, New -> Empty File will be removed as it doesn't do anything useful
  • Cut, Copy, Paste (note: annotation-registered items transferred as XML fragment)
  • Find on folders, perhaps
  • Delete - renamed to Hide, replaced with Restore for _hidden entries when not filtered out
  • Rename, Localize name and Pick Icon - will remain, corresponding reverse operations will be shown on branded (renamed, localized) entries
  • Move to original location - undo operation of items reordered in branding
  • Show Javadoc, Open Consumer Module - new actions; straightforward for annotations, for XML entries uses info published via new SPI (see above)

Alternative Solutions

Let user edit important UI-related categories in separate editor ImprovedBrandingSupport69 (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.

Somehow merge current layer view with annotations, e.g. by letting CoS create generated layers and use them. Annotation-derived items would be read-only.

For #1, have an suite action to generate a read-only view of the SFS, say in the Output Window. Hyperlink every entry to the original layer.xml or annotation.

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