Re: Namespace issues

On Thu, 2002-05-16 at 10:56, Kristian Koehntopp wrote: > > At the moment, I am testing XML/Transformer.php by implementing a few > classes that make use of it. As a typical problem I tried to duplicate the > functionality described in > > http://docs.roxen.com/roxen/2.2/creator/text/foldlist.tag > > This system of tags implements a foldable <dl/> called foldlist > <fl/>. A <fl/> is is written > > <fl> > <ft>Head 1</ft> > <fd>Data 1</fd> > <ft>Head 2</ft> > <fd>Data 2</fd> > </fl> > > and is rendered > > [+] Head1 > [+] Head2 > > The [+] are clickable and expand to > > [-] Head 1 > Data 1 > [+] Head 2 > > In writing such code, I encountered several problems which need > a PEAR global solution, since they are namespace issues that > will arise again in all classes that have similar requirements. The > issues are > > 1. Use of the URL namespace of the webserver > 2. Use of the GPC namespace > 3. Use of sessions (enabling them) > 4. Use of sessions and GLOBALS namespace > > Please read on: > > 1. Image namespace issues/URL namespace issues > > The foldlist requires the use of two URLs for images, the > folded and unfolded arrows, denoted [+] and [-] in my ASCII > representation. > > At the moment, I store them as /internal-pear/foldlist/folded.gif > and /internal-pear/foldlist/unfolded.gif. > > That is, as a PEAR global rule, > > "For the admin/application developer: > PEAR reserves the right to use the /internal-pear branch in > your webservers URL namespace tree. Your application must > not use URLs starting with /internal-pear for its own > purposes. > > For PEAR developers: > Any PEAR class that needs URLs may use names below the > /internal-pear/<classname>/ branch in a webservers URL > namespace tree." > > What are your opinions on this? Hi Kristian, You just ran into part of the problem with the "application" part of PEAR. :-) A namespacing mechanism like you suggest is of course necessary. I think /internal-pear is fine as a prefix/directory, but it should be per package, and not per class (like Martin and Sebastian have suggested already). The biggest problem where is configuring the web server. I want to integrate PEAR with at least Apache so that when you install an application, you may have the necessary changes applied to your httpd.conf too. My intention has to let people choose between setting up a virtual host "%s.example.com", where %s is the application name, or a subdirectory "example.com/%s/". Your suggestion brings up another issue I had not considered before: some URIs on the web server should be available on all virtual hosts, which means you need a lot of aliases for each vhost (like Martin mentioned), and it requires a lot of maintenance when installing new packages. It's solvable, but doesn't scale very nicely. Not sure if there are any ways around it though. In order to implement this, PEAR needs two new file roles in package.xml: an internal htdoc (available on every vhost), and a per-application htdoc (available on the app's vhost). I suggest "int-htdoc" and "app-htdoc" Next, the default "int-htdoc" location must be specified in PEAR_Config, for example as a sprintf format string ala "internal-pear/%s" (relative to document root). It has to be there because the installer needs to know where to install the int-htdoc files. (Moving them while still keeping things plug-and-play is not trivial.) How the "app-htdoc" files are treated depends a bit on how the Apache integration would be. So far I've been toying with the idea of letting people choose between a vhost or subdir-based setup. > 2. GET/POST/COOKIE (GPC) namespace issues > > The foldlist requires self-submitting URLs with GET > parameters to activate state changes from folded to unfolded > and back. These parameters names must not clash with > application used variable names. > > At the moment, I use internal_pear_foldlist[]. > > That is, as a PEAR global rule, > > "For the admin/application developer: > PEAR reserves the right to use GPC variable names > starting with internal_pear on any page. Your application > must not use GPC variables starting with internal_pear. > > For PEAR developers: > Any PEAR class that needs GPC parameters may use names > starting with internal_pear_<classname> in the GPC > namespace. > > Again, your opinions on this? Fine, except I'm not too happy about the long prefix here. There's something in the back of my head telling me to limit the length of cookie names, so _pear could be a better prefix for GPC vars. Of course, if we change this convention for GPC, it would make sense to change it for the htdoc files too. > 3. Session storage and session use > > The foldlist needs to store state, and I want to use sessions > to do so. I do not want to interfere with session management > of the application, and I want to thread lightly on the need > to include class code on every page, which would be necessary > when an object becomes part of the session. > > What is the current way of the PHP session handler regarding > the storage of objects in a session? That is, > > a) what happens when an object is part of the session and > the class include for that object has not been loaded > on all pages? Does the object keep its class and methods > on the following pages? > b) when does the class of an object has to be included for > such objects are part of the session, i.e. what happens > when a class include is being loaded after the session_start() > call? When does a class have to be included when the > session is auto started in php.ini? Does one have to > include the class code in auto_prepend_file in such > cases? > > On a PEAR global scale: > > When a PEAR class needs sessions, what kind of code is > required to check that sessions are not already started, and > if not, to start the session? Should PEAR classes start > sessions themselves or should the session management > configuration be left to the PEAR class user > (administrator/developer) and only be noted as a requirement? > > Should PEAR classes store their objects as part of the session > or should they store a classless hash as part of the session and > use that hash instead of their object-internal data, in order > to keep the size of the session small and in order to save code > includes which must be part of each and every page? > > What is, in your opinion, the correct way to handle this? Storing objects in sessions is sexy, but it adds a lot of bloat too. IMHO, everything implicit should be light-weight by default, or PEAR will end up as a resource hog that noone can use for really busy sites. AFAIK you can't have use two sessions simultaneously, so PEAR should "leech" on the current session if there is one, and add variables called _pear_<name>, or create a session if needed. If you _can_ have simultaneous sessions, it's easier of course. > 4. Namespace in Sessions and in GLOBALS > > How do we handle namespace issues in sessions? When a PEAR > class wants to use variables that have to become of the session, > or of the global namespace, what names do we reserve here? > > Again, I propose internal_pear_<classname> for use by PEAR. > > What are your opinions on this? Namespacing for $GLOBALS is already documented and widely used: _<package>_<variable> http://pear.php.net/manual/en/standards.naming.php - Stig