Bug 197161

Bug #191407 comment #9:
> by omitting preferredID in @TopComponent.OpenActionRegistration one can create
> actions that do not work with singleton components, but with unlimited
> instances.

This is now in use in the PaintApp sample; each time the action is selected, a new document (canvas) appears.

But this behavior seems to rely on an undocumented (?) subtlety of layer semantics in OpenComponentAction.getTopComponent. Specifically, <attr name="component" newvalue="org.netbeans.paint.PaintTopComponent"/> causes map.get("component") to create a fresh instance each time rather than caching the attribute value as I would have expected (and as the general contract of Map would lead you to expect). Perhaps this happens to work in the current impl of BinaryFS, but other layer impls might decide to cache attr values such as 'component' which may be expensive to create - in which case the action would merely reopen/refocus the first and only canvas to be created, breaking a fundamental aspect of the application's UI.

For a non-singleton TC, what you ought to be registering statically is not an actual TC instance, but some sort of factory for TCs. This might be done without a public API change as a new attribute such as 'String componentClass' created by TopComponentProcessor and interpreted by OpenComponentAction. (Only available for modules compiled with the new version of the processor!)

In the meantime I do not recommend anyone use @OAR without a preferredId; you can just as easily register a regular action (@ActionRegistration) which explicitly creates a new TC and calls open() and requestActive(). In fact I recommend that in 7.0, preferredId be made a mandatory attribute of @TC.R when @TC.OAR is also specified, to prevent the bogus implementation from being used in production NB versions.