---

PlatformX: the NetBeans Extended Platform Project

This is the brainstorming page for the Extended Platform. This page will change and be broken up in the coming months as the project matures.

What is PlatformX? A lot of people build applications on NetBeans. There should be a place where the general-purpose things people write can go live and be of benefit to others. A peer-maintained repository of useful NetBeans modules that, while not necessarily useful in an IDE, are very useful in an RCP application.

What Belongs Here?

There is already the contrib project for IDE modules. The ext project will have an incubation area for new modules/technologies. Things that are not in the incubation area must be in use (or soon to be) in at least one RCP application; they should have unit tests and have been through NetBeans (or equivalent) API review and conform to the API design standards that other NetBeans modules conform to. In some cases, the extended platform will incubate replacement or wrapper APIs for things that are doable in NetBeans, but the API is either old and poorly designed or overly difficult to work with.

How do things go from here to the Platform-proper?

They don't necessarily. The goal here is to create useful things that many people need and maintain them collaboratively. That shouldn't involve a dependency on the people directly building the NetBeans Platform. This is an independent effort. Of course it would be nice if this work were adopted that broadly, but our primary goal here is to solve our own problems, not force a solution on the rest of the world.

Where is it?

Currently its mercurial repository and continuous builds are hosted on a staging server owned by Tim Boudreau until more initial contributions are in place and space has been set up on the main NetBeans hg repository.

Brainstorming

Things that the extended platform should consider providing, in the opinion of Tom Wheeler (those prefixed with 'TW' are things which Tom is already working on):

• Improved wizards API
• Special module type which uses system classloader (handy for third-party libraries which use reflection)
• ExtPlatform binaries available for download
• (TW) More flexible build harness
• Faster builds
• A special module type which uses the system classloader (to workaround broken third-party libraries which make invalid assumptions about classloaders but which a developer may not be able to rewrite)
• (TW) Better Undo/Redo support (e.g. ability to decorate a TopComponent with an UndoRedoManager)
• Better support for derivative platforms (improved suite chaining)
• Less dependence on a particular view; should be easy to replace default UI components
• (TW) Improved UI components, including property sheet
• More built-in property editors (dates, for example)
• More explorer manager types (cover flow and contrib/ttv, for example)
• Make it easier to work with DataObjects (see contrib/pojoeditor and contrib/objectloader)
• Allow registration of actions based on node Lookup content (see contrib/dynactions)
• (TW) Ability to build Win32 (and other platform) installer files "out of the box"
• (TW) Enhanced branding support (changing launcher icon, etc.)
• Easier to implement cut, copy, paste, drag and drop
• Ability to build custom platform (see Jarda's dvbcentral project's platform.xml for inspiration)
• (TW) Ability to include NBM files into platform
• Support for Modules Owned By Multiple Suites
• Remove restriction that a package can not exist in two or more modules
• (TW) Build/merge Javadoc for all modules in the suite
  • Ideally this should include both source and library modules
• Distribute via BitTorrent
• Other things listed on the post-6.0 Wiki that don't make it in 6.1 should be considered for ExtPlatform, especially:
  • Additional API Support wizards

Wade Chandler notes:

• Dialog Mode -- This would be handy for applications needing toolbox type windows which are configurable and dockable.
• Login and Security Infrastructure -- This is common in enterprise and business type applications. It would be nice to tie menus and top components into different security roles and they could be disabled and/or hidden depending on the need. Look into what it would take to replace to make this doable.
• (WC)GlassPane at the TopComponent level or at least a TopComponent extension class which could be used instead of extending TopComponent which would allow a GlassPane to exist at the TopComponent level just as they exist at the Window level This has already been mostly implemented in the code repository

Fabrizio Giudici notes:

• Floating, translucent TopComponents (see for instance Apeture "Head Up Displays": )
• Capability of customizing the l&f of Wizards (e.g. the background graphics)
• Integration with Quaqua out-of-the-box
• More compliance with Apple HIG on Mac OS X (e.g. double fonts in pop ups, button conventions)
• Transparent support for JSheet on Mac OS X (by means of Quaqua)
• Simplifying things with annotations, dependency and resource injection and making things compatible with Spring (e.g. transactions)
• SVG icons
• "Enhanced" Views
• "Enhanced" Actions