Bug 169338

Might as well make the API able to handle turning on/off recursion on folders, too.

Created attachment 85360 [details]
Proposed patch (missing apichanges)

Please review this API enhancement.

Y01 Don't use the file terminology. The Lookup is supposed to be XML filesystem neutral. Don't use .instance as 
suffix. 

Y02 The enum options look too complicated to me and not all options are supported in other cases than on XML 
filesystem.

Y03 UnsupportedOperationException is unpolite and I do not want to introduce such concept into Lookup API (this would 
be the first use).

Y03 To get single instance is imho possible in current API: Use Lookups.forPath("some/folder").lookup(new 
Template(YourClass.class, "SL/path_without_extension", null)). We can certainly invest in improving performance and 
beatify this API calls. I'd rather see such optimization than the propose API extensions.

Y04 If you care only about XML filesystem, consider adding file system specific solution:
<T> T FileUtil.getConfigObject(Class<T> clazz, String path).

Y01 doesn't make sense to me. If you are looking up a file path, you have the file name including suffix.


Y02 part 1 (too complicated) - not much I can say to that.


Y02 part 2 / first Y03 - don't see any way around it other than Y04.


Second Y03 (misnumbered) - that is a very poor substitute. Using InstanceCookie directly would be preferable.


Y04 (misnumbered) - I think that would work. The clazz parameter is not particularly helpful in that case - could just
cast the result if needed. Anyway this would be an entirely different patch (possibly using NamedServicesProvider,
possibly not) which I no longer have the inclination to spend time on unless there is a fresh request.

"(possibly using NamedServicesProvider, possibly not)" - I suggest to use NamedServicesProvider, if possible. The 
openide.filesystems would recognize only .instance and as soon as settings module is in the system, .settings files 
would be recognized as well. This would be consistent with the file to object interpretation used by Lookups.forPath.

Reopening as an alternate API based on Y04 should still be considered.

Y03(2) does not handle the case that you want to get an Action (as described here - http://www.nabble.com/Calling-an-existing-action-from-a-module-
td25874462.html - user wants to invoke an action provided by core if present, but it presumably should fail gracefully if not present, and the caller does not 
have access to the implementation class [and should not], only javax.swing.Action).  Y04 could work for that, though.

Feel free to assign back to me.

Created attachment 108975 [details]
Ready to integrate patch

[JG01] isData check in RecognizeInstanceObjects should be unnecessary; if there is some loader which offers InstanceCookie on a folder, it ought to be honored.

OK, I'll remove the isData check and integrate tomorrow.

Integrated as http://hg.netbeans.org/ergonomics/rev/3fa3a72c7e69

I've also added a sample use of the API in subversion:
http://hg.netbeans.org/ergonomics/rev/1ef70a4c8bd0
I'd like to write a hint to detect the FileUtil.getConfigFile().getAttribute("instanceCreate") and convert it, if I knew some simple way...

I added some more sample usages in core-main #14016a26fa33. There do not seem to be many places left, but if you are looking for some, try spi.debugger.ui/src/org/netbeans/modules/debugger/ui/actions/DebugMainProjectAction.java and welcome/src/org/netbeans/modules/welcome/ui/PluginsPanel.java for example.

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/3fa3a72c7e69
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #169338: Introducing FileUtil.getConfigFile