Re: Earthquake in Text_Wiki

On May 27, 2004, at 3:33 AM, Jan Schneider wrote:

if (!empty($app)) { require_once $app . '/lib/Cache/' . $driver . '.php'; } elseif (@file_exists(dirname(__FILE__) . '/Cache/' . $driver . '.php')) { require_once dirname(__FILE__) . '/Cache/' . $driver . '.php'; } else { @include_once 'Horde/Cache/' . $driver . '.php'; }

OK, so: dirname(__FILE__) refers to the directory holding the current file. However, the problem I run into is how to get to the file in the first place.

You actually missed the interesting part of that construct. ;-)

How typical of me. :-)

I talk about the first if-clause. Let's see where this $app variable comes from and take a look back at the start of the method:

    function &factory($driver, $params = array())
    {
        if (is_array($driver)) {
            $app = $driver[0];
            $driver = $driver[1];
        }

You actually have to ways to specify the driver, with or without the file location. You can call the factory like: $rule = &Text_Wiki_Rule::factory('Bold', $params); loading the default Bold rule that comes with Text_Wiki from Text/Wiki/Rule/Bold.php. But if you call it like: $rule = &Text_Wiki_Rule::factory(array('/home/jan/MyTextWiki', 'Bold'), $params); it could instead load the rule file from /home/jan/MyTextWiki/Rule/Bold.php or whatever path structure you chose in the first if-clause. In our APIs we expect custom drivers to be in lib/Package/driver.php but you can of course choose whatever you like or even let the user set the path to the driver file completely: $rule = &Text_Wiki_Rule::factory(array('/home/jan/MyTextWiki/Rule/Bold.php', 'Bold'), $params);

Still good stuff. However... ;-) Rules are no longer single files. To implement the Horde method you describe, for Text_Wiki, would require that the user be able to specify locations for... * The parser class for the rule * The main rendering class for each format (XHTML, PDF, RTF, DocBook, perhaps others) * The rendering class for each rule for each format With just three rules and three formats, that translates to... * 3 rule parsing classes * 3 format classes * 9 rule-format rendering classes ... 15 file locations that the user has to handle. Text_Wiki expects to support at least 6 formats (XHTML, DocBook, LaTeX, RTF, PDF, and Plain) and currently has 35 rules. That would be a complete mess for the end-user if they wanted to specify, say, two custom parsers and four custom renderers, because the end-user would have to sit down and walk through the file-location-specification array (which has to track 35 + 6 + (35 * 6) = 251 files) to see where to put in the locations. God help the end-user who wants to add a completely new rule under this system; he has to insert it into the rule stack with the parser location and six rule-format rendering file locations. Yes, one could write a method automate part of it, but the point is that the end-user has to figure out what everything means; it's non-intuitive enough under the current system, and continuing in that vein would only extend the complexity. I want simple stuff where I can get it. As such, I still don't think the Horde way of doing it is an intuitive option. It seems much easier to me to say "look for files conforming to a naming convention in '/path/to/files/' or '/some/other/place/'" and let the Savant-style file-finder do its work. Is this slower? Probably, but as Alan noted, it's already terribly slow from the regexes. Is the Savant-style way easier for the end-user to comprehend quickly? Well, I think so -- but as usual, I may be wrong, and am happy to continue the discussion. :-) -- Paul M. Jones Savant: the simple alternative to Smarty for PHP. http://phpsavant.com/ DB_Table: build RDBMS tables and XHTML forms in one PHP class. http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table Yawiki: your collaborative online documentation system. http://yawiki.com/ Yawp: a single-file foundation for PHP applications. http://phpyawp.com/