Re: Using GlobFilenameFilter with Path+filename instead only filename

["Daniel F. Savarese" <df...@savarese.org>]

In message <17...@www37.gmx.net>, "Thomas Zillinger" writes:
>I understand that by design it seems that GlobFilenameFilter only evaluates
>the pathname.getName() part of a file (see RegexFilenameFilter). I was

It's required by the FileFilter and FilenameFilter interfaces.  That's
how they're expected to work.

>wondering if it is easy to write a 'GlobFileFilter' which evaluates the
>whole path of a file so I could pass it a pattern like:
>     myimages/lang_*/*.gif
>and it correctly accepts a path like:
>     D:/mywebapp/myimages/lang_en/test.gif

If you want to do this for your own purposes (as opposed to passing the
filter to a class like JFileChooser which expects the FileFilter interface
contract to be fulfilled), it's not easy to subclass GlobFilenameFilter
for that purpose because the matcher and pattern in RegexFilenameFilter
are not protected.  Otherwise, you'd just override accept to return
_matcher.matches(pathname.getAbsolutePath(), _pattern).  So I'd say you've
exposed what is arguably a design flaw.

If there's a desire to make RegexFilenameFilter more customizable, would
folks prefer that the matcher and pattern be made protected or for a
public or protected accept(String) method be added?  Or both?
accept(File dir, String filename) would be implemented asl accept(filename)
and accept(File pathname) would call accept(pathname.getName()).  That
way, to do what you want you'd just have to override accept(File pathname)
and make it call accept(pathname.getAbsolutePath()).  We're in between
minor version number releases (2.1 will be the next release) so now's
the time to get in your API addition requests.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: oro-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-user-help@jakarta.apache.org