jakarta-oro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Lipofsky <dlipof...@kurion.com>
Subject RegexFilenameFilter
Date Thu, 22 Feb 2001 00:51:40 GMT
I noticed the 4 param RegexFilenameFilter constructor
   RegexFilenameFilter(cache, matcher, regex, options)
does not pass on the options to setFilterExpression.

Also, we could easily have RegexFilenameFilter also
implement both FilenameFilter and FileFilter.  The
code is below.  I suggest we do this.

  /**
   * Filters a filename.  Tests if the filename EXACTLY matches the pattern
   * contained by the filter.  Only the last component (File.getName()) is
   * examined.
   *
   * @param file  The File object to run the filter against.
   * @return True if the filename EXACTLY matches the pattern, false if not.
   */
  public boolean accept(File file) {
    synchronized(_matcher) {
      return _matcher.matches(file.getName(), _pattern);
    }
  }

Alternately we could have both RegexFilenameFilter and
RegexFileFilter, GlobFilenameFilter and GlobFileFilter, etc.
It seems better to just implement them both in one class
except it might be confusing to have something named
*FilenameFilter that implements FileFilter.   Also see
my next point.

A feature I found I needed was to let all directories
through the filter and only filter the files (good for when
you want to recurse).  This only works well for
FileFilter.accept - for FilenameFilter.accept you would have
to make a new File object out of the parent File object and
the filename, which is wasteful.  It wasn't hard to extend
GlobFilenameFilter to do this, but does anyone else consider
it a good optional feature for the ORO package?
- Dan

p.s. any releases planed soon?

Mime
View raw message