Re: [PEPr] Proposal for PHP::ApplicationVars
| From: | Davey | Date: | Wed, 24 Dec 2003 19:38:04 +0000 |
| Subject: | Re: [PEPr] Proposal for PHP::ApplicationVars | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-24631@lists.php.net to get a copy of this message | ||
Alan Richmond wrote:
Hi, While I agree with the usefulness of shared-scope, or "application" variables, and would love for the PHP core, or at the minimum a PECL extension, to have an $_APP super-global and transparent handling, what this class does is already achievable with existing PEAR classes. This is Cache_Lite with a simpler interface, fewer options and without the file locking that's required for shared use. Application specific scopes can be set by using groups in Cache_Lite, or the Cache_Application extension of Cache. The proposed extension for using DB for storage is already met by Cache_Application via Cache's present support for DB and several other containers. I like it (except for not flock()ing cache files) and use something similar myself but I don't think it should be it's own class. Maybe extend or composite Cache_Lite as Cache_Lite_Application? -AlanAlan, FYI, Pollita (Sara Goleman) mentioned a PECL package for registering new superglobals, that I believe she is working on. I could easily tie $_APPLICATION (my preffered variable name) to my class. Also, this was a proof of concept, I will add flocking. However, my main concern here is that standard $_SESSION variables are tied to the APPLICATION. The only way around this is using a seperate file for Application vars, not a big problem... just need to re-write (which I've mostly done anyways) the standard PHP Session handling into userland code + storing $_SESSION[ASID] in its own file. Probably the best solution actually. I would actually like to have what ColdFusion (MX only?) has, which is that you need to tell it to lock the application vars stuff, otherwise it assumes the data can be "corrupted". I mean, a lot of stuff that this will be used for, would prefer speed to data accuracy. Again, using a database, is the BEST solution all round, that way sessions are NOT tied to an Application and file locking is unnecessary. - Davey