[pmwiki-users] Slightly different local/config behavior . . .
Patrick R. Michaud
pmichaud at pobox.com
Sat Feb 19 14:49:14 CST 2005
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'):
> conditionalRequire('$action', $val, $script);
I'm assuming you're referring to lines like the following in
## 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
- 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"
> 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
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.
More information about the pmwiki-users