* Soxred93 <soxred93(a)gmail.com> [Mon, 20 Dec 2010 23:21:34 -0500]:
Hi all,
Recently, I've been working with the Symfony web framework [1]. One of
the classes they include is called the sfFinder class [2], which is a
fluid, easy-to-use file finder class. It searches for files or
directories in the filesystem, using a fluid PHP 5 interface. It has
no
dependancies, so it should work fine with MediaWiki.
After finding
numerous instances of opendir(), readdir(), closedir(), etc. in
MediaWiki, I thought that it would be a good idea to use one
centralized
class to do all file searching. There is only 1
potential issue I see,
though. It is MIT licensed, which is GPL compatible, so it should be
okay to implement it, but I'm not too clear on this issue.
The usage is simple:
sfFinder::type('file')->name('*.php')->in('/path/to/dir');
//list of
PHP
files in directory and all subdirectories
sfFinder::type('file')->name('*.php')->in('/path/to/dir')->recurse(0);
//list of PHP files in that directory only
sfFinder::type('dir')->name('foo')->in('/path/to/dir');
//list of
directories with the name "foo"
There is documentation at [3], but it's for an old version. The code
is
very similar though, so most of it should apply to the
current
version.
What would people think of a change like this. I would like to see
this
happen, but I'd like some more opinions before I
look into
implementing
it.
The optimal way to use a framework is to integrate it through the whole
code base. For example, special pages, actions may use Symphony routing.
I do agree that GlobalFunctions are somewhat outdated (although the
calls are short and compact). Also some basic classes such as WebRequest
or Xml or Http are not powerful enough. Perhaps some framework would be
better to use (but slower?).
Dmitriy