Bug 169338 - FileUtil.getConfigObject(String path)
FileUtil.getConfigObject(String path)
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
6.x
All All
: P2 with 1 vote (vote)
: 7.1
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST, PLAN
Depends on:
Blocks: 58991 205798
  Show dependency treegraph
 
Reported: 2009-07-28 14:30 UTC by Jesse Glick
Modified: 2011-12-01 17:58 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (missing apichanges) (18.48 KB, patch)
2009-07-28 16:26 UTC, Jesse Glick
Details | Diff
Ready to integrate patch (13.74 KB, patch)
2011-06-18 15:18 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-07-28 14:30:18 UTC
(SomeType)
DataObject.find(FileUtil.getConfigFile("...path.instance")).getLookup().lookup(InstanceCookie.class).instanceCreate()

is awkward and forces you to depend on Datasystems. Nicer would be:

Lookups.forPath("...path.instance").lookup(SomeType.class)
Comment 1 Jesse Glick 2009-07-28 14:49:41 UTC
Might as well make the API able to handle turning on/off recursion on folders, too.
Comment 2 Jesse Glick 2009-07-28 16:26:35 UTC
Created attachment 85360 [details]
Proposed patch (missing apichanges)
Comment 3 Jesse Glick 2009-07-28 16:28:12 UTC
Please review this API enhancement.
Comment 4 Jaroslav Tulach 2009-08-03 12:47:21 UTC
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).
Comment 5 Jesse Glick 2009-08-03 15:13:42 UTC
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.
Comment 6 Jaroslav Tulach 2009-08-03 15:49:54 UTC
"(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.
Comment 7 Jesse Glick 2009-10-13 17:52:13 UTC
Reopening as an alternate API based on Y04 should still be considered.
Comment 8 _ tboudreau 2009-10-13 19:52:08 UTC
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.


Comment 9 Jesse Glick 2010-11-24 16:13:20 UTC
Feel free to assign back to me.
Comment 10 Jaroslav Tulach 2011-06-18 15:18:54 UTC
Created attachment 108975 [details]
Ready to integrate patch
Comment 11 Jesse Glick 2011-06-21 18:45:37 UTC
[JG01] isData check in RecognizeInstanceObjects should be unnecessary; if there is some loader which offers InstanceCookie on a folder, it ought to be honored.
Comment 12 Jaroslav Tulach 2011-06-28 07:09:10 UTC
OK, I'll remove the isData check and integrate tomorrow.
Comment 13 Jaroslav Tulach 2011-06-30 07:05:13 UTC
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...
Comment 14 Jesse Glick 2011-06-30 17:35:31 UTC
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.
Comment 15 Quality Engineering 2011-07-01 14:07:37 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/3fa3a72c7e69
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #169338: Introducing FileUtil.getConfigFile


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