On Wed, Sep 16, 2009 at 08:41:29AM -0400, Daniel Pocock wrote: > I'm a little surprised that we have to check the existence of the > variable every time it is used - I looked at index.php and graph.php, > and both of them appear to read eval_config.php before reading functions.php
I agree. There was some discussion a while back about having a centralized 'validation' and 'sanitation' routine through which all variables would be passed before use. To me, the problem seems to be that PHP doesn't treat an undefined value as false in quite the same way as Perl[1]. However, the code is written, in many places, as though it *is* treated the same. So we get lots of these undef warnings in the logs. The code functions, but is noisy. > If the variable's existence is not known at this point in functions > (despite a default value in eval_config.php), then aren't we running the > risk that it's value might have been lost somewhere? I think that may be the case. I was testing this out a little bit yesterday in trunk, and couldn't get the eval_config.php bit to work correctly. Thus, my patch[2]. I'm slightly concerned about adding ad-hoc things like this, and wonder if we need a more general solution to initalizing all of the variables that may be needed. Obviously, there are lots of files in conf.php that should be included at all times. There are also lots of things in get_context.php as well. And just to make things interesting, there's the issue of conf.php being generated from conf.php.in, instead of just included directly. For the conf.php problem, perhaps this idea would work? Leave conf.php alone, as a generated file to allow for install-time customization by the user. Create a new config file that has options that shouldn't usually (but could) be changed by the local admin. Essentially, a "don't change this stuff unless you know what you are doing" kind of file. Yes, changes to this file will make upgrades harder, but the user was warned. If they "know what they are doing," then they can presumably manage to patch the file during an upgrade as well. [1] I won't argue that either way is good or bad. Not here, at least. ;-) [2] If there is a better solution, feel free to revert/replace this patch. -- Jesse Becker NHGRI Linux support (Digicon Contractor) ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
