Re: QuickFormController design change idea/request
| From: | Alexey Borzov | Date: | Sun, 31 Jul 2005 19:39:19 +0000 |
| Subject: | Re: QuickFormController design change idea/request | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-39062@lists.php.net to get a copy of this message | ||
Hi,
Matt Friedman wrote:
We work with QuickForm and QuickForm Controller extensively. We find it exceedingly useful, however, we do have one challenge for which the design doesn't allow a workaround, or at least a workaround that suits us entirely. The issue is with the way sessions are handled. In our case we would like to handle sessions completely decoupled from php based sessions. We store all session data in the database and want to be able to do so without using $_SESSION - we've tried using the session.save_handler feature but this has certain limitations that we aren't satisfied with, specifically, the way php creates and stores the session string. For QuickForm Controller, the session handling is hard-coded into the classes so there isn't a way to plug-in an entirely separate session mechanism.QuickForm Controller does not do any session handling, it just expects that the contents of the $_SESSION array will magically persist between requests. Therefore if you modify you custom session handling mechanish to populate $_SESSION and save its contents everything will work with no changes needed to either QuickForm Controller's or other PEAR classes code.
What I've been wondering is if the authors/maintainers would consider a design change - backward compatible - that has a default session handler but allows the user to plug-in their own session handling object if they wish to. I also wonder if this approach needs to be adopted more pear-wide, but I suppose that is another conversation.