Re: QuickFormController design change idea/request

What I would looking for would be more of an object oriented solution such as accessing the session via some object interface, rather than a data structure (the $_SESSION array). If the session was handled/accessed by an object then you could switch that object and Quick Form wouldn't know the difference. Accessing the array directly causes a dependency on the array with that name and that structure - overwriting the session array is also probably not the clearest thing to do and probably confusing, because the convention is that the array with the name $_SESSION is specifically for php based sessions. With object programming we are trying to hide the data, not expose it to clients. The current way sessions are accessed in Quick Form does just the opposite - it exposes the underlying data structure. Additionally, if I followed your advice I'd have to do some hack like populate my session mechanism and then populate the $_SESSION variable thereby updating data in two different places, something I'm not particularily interested in doing for what should be obvious reasons. Is there no chance of changing the design? I'm hoping I can convince you that this is worthwhile - however, if there isn't interest in changing it let me know as we can work out other solutions. Ideally, Quick Form would extend its already excellent design to apply to this issue. What I mean is the authors have followed front controller design principles nicely for all of the code except for the way sessions are accessed - why not apply this thinking to this issue as well? On 7/31/05, Alexey Borzov <borz_off@cs.msu.su> wrote: > > 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. > > -- -- Matt Friedman