#17 avoid namespace collision

[Greg Rundlett]

I've recently installed plm 3.2.0-rc, and find that the
browser detection script creates a (global) variable
called $browser. [This is 'true' because most hosting
environments have yet to switch over to the
register_globals=off setting] Of course, my website
already has a browser detection script that is used
globally, and it too puts information in a variable
called $browser. I have two choices: change my website
code, or change PLM code, neither of which is very
desirable. Since PLM *must* have browser-detection
(and most websites will also have some browser
detection requirements), why not put the browser
detection functionality into the plm class so as to
avoid namespace collisions?

[Greg Rundlett]

Logged In: YES
user_id=143603

Actually, the (layersmenu-browser_detection.php) browser
detection script appears to just setup the $menuType
variable. There are a couple of easy solutions to avoid
namespace collision here. One method is just to rename
$browser to $plmBrowser. It is not likely that a wesite
would have such a variable in their own scripts, thus
lowering the chances of namespace collision.

To completely eliminate the chances of namespace collision,
the script could encapsulate the variable into the local
scope of a function: plmDetectBrowser ()
then you could make the assignment by calling the function
$plmBrowser = plmDetectBrowser();

See the attached patch for differences applied

[Greg Rundlett]

patch showing differences applied to my local CVS repository which contained the 3.2.0-rc version

[Marco Pratesi]

Logged In: YES
user_id=65709

It can be a good idea, but please consider that in fact
lib/layersmenu-browser_detection.php is not part
of the phplm classes/library, it is just a small piece
of procedural code intended to be only an example
of what you can do using server-side browser detection,
and it is used only in the project's homepage,
i.e. index.php.

One could want to make different choices than the ones
provided in the example (as an example, nowadays,
I usually give to NS4 and msie4 the "TEXT" version),
hence, if I'd write a method using that example code,
who wants to make different choices would have to change
the code of the class, and this against OOP, right? ;-)

Summarizing: that piece of code is only intended as
an example, as a "howto"; the user, reading it, can realize
that such a thing is possible and easy; he will decide how
to do something similar on his site, probably just reusing
*his* already available $browser variable, instead of
the one I have used in my quick'n dirty example.

Marco Pratesi