On Fri, Dec 24, 2010 at 10:27 AM, Soxred93 soxre...@gmail.com wrote:
In the HISTORY file:
* glob() is horribly unreliable and doesn't work on some systems, including
free.fr shared hosting. No longer using it in Language::getLanguageNames()
Was it replaced with opendir()? :)
(A
In the HISTORY file:
* glob() is horribly unreliable and doesn't work on some systems, including
free.fr shared hosting. No longer using it in Language::getLanguageNames()
-X!
On Dec 24, 2010, at 12:24 PM, Brion Vibber wrote:
Glob works too I think.
-- brion
On Dec 23, 2010 12:06 PM,
On Tue, Dec 21, 2010 at 12:36 PM, Brion Vibber br...@pobox.com wrote:
Tell you what -- 10 uses of opendir shouldnt take too long to replace; write
the code and let's see how it actually looks. Us all sitting in the list
bikeshedding won't be much use, but if it makes the code cleaner, hey win!
On Thu, Dec 23, 2010 at 1:47 PM, Chad innocentkil...@gmail.com wrote:
Well it's in trunk now[0] (plus a few followups). It's shorter, yes.
Some profiling before/after would probably be good.
It's shorter by only a handful of lines, at the expense of using an
obscure library rather than built-in
On 12/22/2010 12:16 AM, Platonides wrote:
We are only using opendir for getting a full directory list.
That's a good point. Perhaps what we need is simply a utility method to
list all files in a directory.
In fact, I just realized that PHP already has one. It's called
scandir(). Its only
On 22/12/10 20:03, Roan Kattouw wrote:
snip
Seconded. My opinion on these frameworks aside, I don't think it's
worth pulling in a framework just do handle a few instances of give
me all files in this directory where there's perfectly good
alternatives that, while not as short, are not at all
* Bryan Tong Minh bryan.tongm...@gmail.com [Tue, 21 Dec 2010 08:57:47
+0100]:
On Tue, Dec 21, 2010 at 7:37 AM, Dmitriy Sintsov ques...@rambler.ru
wrote:
The optimal way to use a framework is to integrate it through the
whole
code base. For example, special pages, actions may use Symphony
On 10-12-20 11:56 PM, Bryan Tong Minh wrote:
On Tue, Dec 21, 2010 at 5:21 AM, Soxred93soxre...@gmail.com wrote:
The usage is simple:
sfFinder::type('file')-name('*.php')-in('/path/to/dir'); //list of PHP
files in directory and all subdirectories
On 21/12/10 15:21, Soxred93 wrote:
The usage is simple:
sfFinder::type('file')-name('*.php')-in('/path/to/dir'); //list
of PHP files in directory and all subdirectories
You can use RecursiveDirectoryIterator to do that. There's a cute
example in the online manual comments.
-- Tim Starling
You can. But the main advantage is less writing, more understanding. I see
type('file')-name('*.php')-in('/path/') tp be easier to understand than
RegexIterator(RecursiveIteratorIterator(RecursiveDirectoryIterator('path/to/project/')),
'/^.+\.php$/i', RecursiveRegexIterator::GET_MATCH);
BUt we
I hate these frameworks, so a big -1 from me.
-Chad
On Dec 20, 2010 11:22 PM, Soxred93 soxre...@gmail.com wrote:
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
I'm not looking to integrate these frameworks entirely into MediaWiki; I'm just
talking about this one single file with one single class. (to be fair, it's 3
classes, but they're all in that one file).
-X!
On Dec 21, 2010, at 9:09 AM, Chad wrote:
I hate these frameworks, so a big -1 from me.
On Tue, Dec 21, 2010 at 10:16 AM, Soxred93 soxre...@gmail.com wrote:
I'm not looking to integrate these frameworks entirely into MediaWiki; I'm
just talking about this one single file with one single class. (to be fair,
it's 3 classes, but they're all in that one file).
-X!
M
That's how it always starts.
Oh I'll just use this one piece. Then Ohhh this looks cool...
Before you know it, you're using the whole framework and kicking yourself.
Slippery slope? Sure, but I don't wanna go sliding down.
-Chad
On Dec 21, 2010 11:18 AM, Soxred93 soxre...@gmail.com wrote:
On Tue, Dec 21, 2010 at 8:16 AM, Soxred93 soxre...@gmail.com wrote:
I'm not looking to integrate these frameworks entirely into MediaWiki; I'm
just talking about this one single file with one single class. (to be fair,
it's 3 classes, but they're all in that one file).
Before going into too
Before going into too much detail on the thread, consider what you actually
need out of a fancy directory iterator. Offhand, I really can't think of
many places where that even *happens* in MediaWiki... maybe when purging
thumbnails?
I count 10 instances of opendir() exactly in trunk.
Tell you what -- 10 uses of opendir shouldnt take too long to replace; write
the code and let's see how it actually looks. Us all sitting in the list
bikeshedding won't be much use, but if it makes the code cleaner, hey win!
-- brion
On Dec 21, 2010 9:16 AM, Soxred93 soxre...@gmail.com wrote:
Soxred93 wrote:
Before going into too much detail on the thread, consider what you actually
need out of a fancy directory iterator. Offhand, I really can't think of
many places where that even *happens* in MediaWiki... maybe when purging
thumbnails?
I count 10 instances of opendir() exactly
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
* Soxred93 soxre...@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
On Tue, Dec 21, 2010 at 5:21 AM, Soxred93 soxre...@gmail.com wrote:
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
On Tue, Dec 21, 2010 at 7:37 AM, Dmitriy Sintsov ques...@rambler.ru wrote:
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
22 matches
Mail list logo
