Re: SessionManager
| From: | Kendrick Vargas | Date: | Thu, 28 Jun 2001 18:07:50 +0000 |
| Subject: | Re: SessionManager | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-514@lists.php.net to get a copy of this message | ||
On Wed, 27 Jun 2001, Hans Westerbeek wrote:
> On Wed, 27 Jun 2001, Jon Parise wrote:
>
> > Future PEAR components can just use the native session_*
> > functions without incuring the overhead of calling class methods.
> >
> > I don't see what you're gaining between this:
> >
> > session_name('session_name');
> > session_start();
> > session_register('foo');
> > session_unregister('foo');
> > session_destoy('session_name');
> >
> > ... and ...
> >
> > $session = new Session('session_name');
> > $session->start();
> > $session->register('foo');
> > $session->unregister('foo');
> > $session->destory();
>
> Well how about this (rough idea):
>
> $sesMgr = new SessionManager();
> $myFoo = new Foo("blah"); // construct a Foo object
> $mySesMgr->addVar("myFoo ", $myFoo); // register the object
> // ... perform actions with the myFoo object that changes its inner state
Actually, how about this. Maybe you could just have a bunch of session
initializers that initialize PHP's session routines to use some default
PEAR containers... like:
SessInit::DB_Session("mysql://my:pass@mysql.example.com/database");
this would set all the handlers, etc, and configure them to use a PEAR DB
and some default fields for storage, etc. Aside from that, you could write
a few wrappers, but the only real purpose for that would be consistency.
-peace
--
Let he who is without clue kiss my ass