Jesse, any chance of implementing this for NetBeans 4.0? Looks like it
would be useful in many places.

It's an API change, and not required for a priority bug. Not up to me
whether it goes into 4.0 or not. Talk to whoever controls the schedule.

See our solution in org.netbeans.modules.web.project.ui.JFileChooser

Perhaps it would be generally usable after slight modification.

Mea culpa.
It should be org.netbeans.modules.web.project.ui.JFileChooser

I am sorry. It seems I am too tired. The last correction:
org.netbeans.modules.web.project.ui.FileChooser

*** Issue 23125 has been marked as a duplicate of this issue. ***

*** Issue 43567 has been marked as a duplicate of this issue. ***

*** Issue 46913 has been marked as a duplicate of this issue. ***

I'd suggest something somewhat simpler - don't try to listen to the filechooser
or anything, just something like:

private String pathFromLastPut = null;
private static final String DEFAULT_TOKEN = "default";
public File getLastFolder (String token) {
   String name = token == null ? pathFromLastPut :
Preferences.getUserNodeForPackage (FileUtil.class).get(token);
   if (file == null) {
       file = pathFromLastPut;
   }
   if (!File.exists()) {
       file = System.getProperty("user.home");
   }
   return file;
}

public void putLastFolder (String token, File file) {
   if (file.isDirectory()) file = file.getParentFile();
   pathFromLastPut = file.getPath();
   Preferences.getUserNodeForPackage(FileUtil.class).put (token, file.getPath());
}

Modules can then have whatever contract they want to have for sharing tokens.  I
suppose it would be a little bit nicer to be able to listen to the file chooser
and make it all nice and transparent, but the above solves a lot of it and I
can't imagine it being a big deal to implement.

Re using Preferences, this seems like exactly the sort of thing where it's
perfectly safe to do - trivial data that's never going to break anything by
being global.

Even doing the listening would be pretty painless - have a createFileChooser
method, pass it a token, and attach a weak listener that caches the file path
but can lose the file chooser, and some kind of timer to check if the file
chooser is gone, and if so store the value by the token.  A little more
complicated to do right though - do you want to store the selection even if the
user cancelled the file chooser?  You won't necessarily know.  Rather than a
lengthy debate, the above approach would allow us to solve the major problem
quickly, and give code a choice about whether it really wants to save the value
or not.

*** Issue 66537 has been marked as a duplicate of this issue. ***

*** Issue 66537 has been marked as a duplicate of this issue. ***

*** Issue 68056 has been marked as a duplicate of this issue. ***

*** Issue 82425 has been marked as a duplicate of this issue. ***

*** Issue 152750 has been marked as a duplicate of this issue. ***

See the patch attached to duplicate issue 152750 - I've been using a version of this in another application for some time.

The basic pattern is 
JFileChooser createFileChooser (String adHocKey);
to handle the current directory on initialization.

It also handles the case of needing badging in file choosers - both the platform and project file choosers do this, and
AFAIK all of the above contain copies of the same code.  It also generally makes working with file choosers easier than
remembering abstruse JFileChooser.* constants for most uses in NetBeans.

If you mean to ask for a review, please see

http://openide.netbeans.org/tutorial/review-steps.html

That's exactly what I did, but you closed it as a duplicate :-)

Reviewers, I am requesting review for the attachment to duplicate issue 152750.

http://www.netbeans.org/nonav/issues/showattachment.cgi/73522/FileChooserBuilder.java

in other words.


[JG01] I want to see a complete patch that includes various clients - say, three or more - using the new API with all or
most of its features, and being significantly simplified or functionally improved as a result. (The dozen or so
duplicate issues were filed just for the ability to remember a default CWD by key, but I have not heard requests for the
other features of this API.)


[JG02] Your @see tag on BadgeProvider is incorrect. Try just "@see FileChooserBuilder#setBadgeProvider".


[JG03] Who is going to use BadgeProvider? Not the project chooser, which implements its own highly tuned icon badging
which cannot be accommodated by this interface. Perhaps the platform choosers?


[JG04] preventFileChooserSymlinkTraversal should probably be on by default, maybe even with no option to disable it. It
anyway only applies to Unixy platforms running JDK 5 - the default behavior on JDK 6 is correct.


[JG05] Is issue #82427 still considered important? If so, shouldn't that be covered by FileChooserBuilder as an
implementation detail?


[JG06] Utilities.showJFileChooser should refer the reader to FileChooserBuilder. (BTW you need to use the syntax
@org-openide-filesystems@ to link to a downstream API in Javadoc.)

*** Issue 53023 has been marked as a duplicate of this issue. ***

There should be some ability for users to completely turn this off, as it amounts to a history archive which some may
feel exposes information that other software or persons may consume and abuse.

[JG01] I want to see a complete patch that includes various clients
Easy enough.


[JG02] Your @see tag on BadgeProvider is incorrect. Try just "@see FileChooserBuilder#setBadgeProvider".
Thx.


[JG03] Who is going to use BadgeProvider? Not the project chooser, which implements its own highly tuned icon badging
which cannot be accommodated by this interface. Perhaps the platform choosers?

I just copied the code in java.platform to achieve this for CLDC, and it needs to be done for CDC and others as well; 
anybody implementing something platform-like will need it as well.  Would much prefer the code for this to be in one place.


[JG04] preventFileChooserSymlinkTraversal should probably be on by default, maybe even with no option to disable it. It
anyway only applies to Unixy platforms running JDK 5 - the default behavior on JDK 6 is correct.

If we can be sure there will never be a case where the default behavior is desirable, that sounds good to me.

[JG05] Is issue #82427 still considered important? If so, shouldn't that be covered by FileChooserBuilder as an
implementation detail?

Yes, it should.  I'd rather get the API in place, and then if we want to do that (it sounds like maybe Dafe already did
for some file choosers), do that after some people are using it - i.e. debug one thing at a time.

[JG06] Utilities.showJFileChooser should refer the reader to FileChooserBuilder. (BTW you need to use the syntax
@org-openide-filesystems@ to link to a downstream API in Javadoc.)

Ok.

> There should be some ability for users to completely turn this off

We can provide a system property to disable it, e.g. -J-Ddisable.filechooser.history=true

Annoying that hg doesn't include things added with 'hg addremove' in a diff unless you commit them locally.  Anyway,
diff attached;  I'll also attach an updated version of FileChooserBuilder.

Created attachment 73937 [details]
Diff of module to use this API

Created attachment 73938 [details]
Updated FileChooserBuilder

"hg doesn't include things added with 'hg addremove' in a diff" - uh, yes it does. Make sure you have

[diff]
git = 1

in your ~/.hgrc (though you should not need that just to get added/removed files displayed). For more, see

http://wiki.netbeans.org/HgHowTos#section-HgHowTos-DevelopAPIReviewPatchesUsingMQ


JG06 - The syntax in Utilities.java is wrong. @org-openide-filesystems@ refers to the root of the foreign Javadoc. You
still need to interject a path and manually construct the hyperlink. Something like

@see <a href="@org-openide-filesystems@/org/openide/filesystems/FileChooserBuilder.html"><code>FileChooserBuilder</code></a>

but try actually building Javadoc and verifying that the link works.


[JG07] Do not use new FileChooserBuilder(getClass()). Use new FileChooserBuilder(ThisClass.class). Otherwise the key
will silently change when the method is ever called on a subclass. (We have the same rule for NbBundle.)

[JS01] The current dir is not saved. Please, fix NbPreferences.forModule(FileChooserBuilder.class).put(dirKey, dirKey).

Yup, already fixed.

All comments addressed, tests added and documentation improved; committed in changeset f989a1086333

Notes:
 - System property allow.filechooser.symlink.traversal can be used to disable preventing symlink traversal;  it is on by
default, this is just in case there is some weird corner case in the future
 - System property forget.recent.dirs will disable collecting of directory history (but not delete anything already
written to NbPreferences)