This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||@TopComponent.OpenActionRegistration misimplemented for non-singletons|
|Product:||platform||Reporter:||Jesse Glick <jglick>|
|Component:||Window System||Assignee:||Jaroslav Tulach <jtulach>|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:|
Description Jesse Glick 2011-03-28 16:14:13 UTC
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.
Comment 1 Jaroslav Tulach 2011-04-25 19:18:59 UTC
> But this behavior seems to rely on an undocumented (?) subtlety of layer > semantics. Specifically, <attr > name="XYZ" newvalue="org.netbeans.SampleClass"/> causes > map.get("component") to create a fresh instance each time rather than caching > the attribute value I guess the simplest way is to document and test for this behavior in the filesystem TCK.
Comment 2 Jesse Glick 2011-04-28 07:34:27 UTC
Would seem simpler and safer to just switch the registration to a componentClass attribute that makes no special assumptions about FS implementation details.
Comment 3 Jaroslav Tulach 2011-06-27 07:29:57 UTC
I've documented and tested the current behavior in ergonomics#43c82c60d43d
Comment 4 Quality Engineering 2011-06-28 14:07:26 UTC
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/43c82c60d43d User: Jaroslav Tulach <firstname.lastname@example.org> Log: #197161: Documenting the current behavior