[pmwiki-users] Slightly different local/config behavior . . .

[Patrick R. Michaud]

On Sat, Feb 19, 2005 at 12:56:24PM -0600, Ben Wilson wrote:
> I'm seeing a lot of "noise" in the new config:
>     if (this = that) then require_once();
> How about a custom function akin to Markup?
>     action_require('edit', 'script.php'):
>     or
>     conditionalRequire('$action', $val, $script);

I'm assuming you're referring to lines like the following in 
sample-config.php:

    ##  The refcount.php script enables ?action=refcount, which helps to
    ##  find missing and orphaned pages.  See PmWiki.RefCount.
    # if ($action == 'refcount') include_once('scripts/refcount.php');
    
    ##  The rss.php script enables ?action=rss and ?action=rdf, which
    ##  provides RSS feeds for a site based on WikiTrails.  See PmWiki.RSS.
    # if ($action == 'rss' || $action == 'rdf') include_once('scripts/rss.php');

Personally, I find the 'if' statements to be far superior to a custom
function, even for a PHP newbie:

   - Just from looking at the name, it's not obvious what 'action_require'
     or 'conditionalRequire' does -- it would need some sort of explanation
     or documentation somewhere.  OTOH, most people (even those new to PHP)
     can look at the if statement and directly figure out that the
     refcount.php script is being included when the action is 'refcount'.

   - It's hard to represent complex conditionals in a function call.
     For example, how could one easily represent the 
     ($action=='rss' || $action=='rdf') condition in a call?  (Yes,
     one could call the function twice, once for each value.  How
     about an && condition, then?)

   - Performing an include from within a function changes the scope
     of variables in the included file -- they become local to the
     function instead of global.  Thus any included files would
     need to explicitly declare all of their global variables (not that
     this is a bad thing).  While this could be easily done for 
     PmWiki's distributed scripts, it might cause confusion for 
     cookbook recipes.

   - The if statements serve as a good (yet readable) example that the 
     config file isn't limited to simply setting variables -- other
     code can be placed there as well.  Prior to placing examples like
     these in the sample-config.php, some administrators assumed that
     config.php could only contain simple configuration variable settings.

   - In this case, the if statements are actually just an optimization;
     i.e., we don't *have* to test $action to include those scripts,
     we could just always include them.  But by testing $action, we
     avoid loading and compiling the scripts when it's fairly obvious
     they won't be used.

> Also, is there a reason for preferring multi-string quotes to a
> HEREDOC? "I see a lot of multiple line strings like this one"
> when<<<END
> I personally prefer a HEREDOC like this. I'm assuming there's a
> performance difference somewhere.

Do you mean "multi-string" quotes or "multi-line" quotes?  I'm
going to assume you mean multi-line quotes -- i.e., strings that
use more than one line of the source text.  (As you can see from
the quoted text above, your "multiple line string" showed up in
as one line in my mail reader -- I'm assuming it was multi-line
when you sent it. :-)

The quick answer is that I generally don't find heredocs to be 
substantially cleaner or easier to read than double-quotes.  One 
still has to escape the $'s that appear in the string (although
the double-quotes no longer need escaping, but I don't have many
double-quotes in my multi-line strings anyway).

Also, according to the PHP documentation, heredocs may not be
portable across operating systems.  The "Warning" box in 
http://www.php.net/manual/en/language.types.string.php says:

    It's also important to realize that the first character before 
    the closing identifier must be a newline as defined by your 
    operating system. This is \r on Macintosh for example.

I read this as saying that if I use a heredoc in a script file
generated on my Linux system, where newline is defined as \n, then
that script won't work on a Macintosh unless the newlines are
first converted to \r in the script file.

Pm