Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Jason Barnett wrote:
Adam wrote:
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
Well ok, but why can't you just have saveToSession() in the conditional
block?
?php
$_SESSION['Request'] = Request::getInstance();
look $_SESSION['Request'] is now a reference to the Request getInstance();
when this session is closed the object will automatically be serialized - no
need
to saveToSession or whatever! just make sure you have always declared the
Request class
before you start the session.
so have the Request::getInstance() deal with checking/setting
$_SESSION['Request'] internally.
if ($_SESSION['Request']-isRefresh() ) {
$_SESSION['Request']-saveToSession();
/* etc. */
exit();
}
/* Rest of script follows here */
?
IMHO the point of OOP is to keep each function split into the minimal
functionality that you need. This allows you to reuse code easier
because a function does only the *minimum* amount of work necessary
instead of extra (unintended) functionality.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
2) must provide mechanism for generating per session uniqe request
identiers. now implemented as md5($_SESSION[next_reqest_id]++) not very
effective but handy:-P
3) must be serializable (this is why i can not put that session manipulation
at __sleep function)
these requirements (1,3) cast out __destruct, __sleep and explicit call to
some saveToSession function. do You have any other idea when to store this
information , please?
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
*doh* i don't know how could i coverlooke taht user reaction:-( thank You.
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
Isn't __destruct is called even if reference count is gr then zero as a part
of script finalization? imo yes -- i tried this with echoing something
within singletons destructor (no invoke with explicit delete:-) and it
worked.
BR
a3c
- Original Messages -
Hallo everybody,
hope I am writing to correct mailinglist(^_^*)...
Absolutely!
I have troubles with sessions and descructor in php5. Can not set session
variable in destructor when it's called implicitly. Do You know solution
please?
I think problem is that session is stored before imlicit object
destruction
*doh*
example.php:
?php
session_start();
session_register(variable);
*Note* You don't need to use session_register() if you use $_SESSION.
In fact this probably isn't even doing what you think it is. Using
$_SESSION indexes is the preferred way to go about using sessions.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
}
}
$req = Request::getInstance();
$req-doSomeThink();
echo This should be hallo 2nd time: . $_SESSION[variable];//
unfortunatly this is not set
echo a href='example.php'Click and cry;-(/a;
// implicit desturctor call
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
?
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Adam wrote:
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
Well ok, but why can't you just have saveToSession() in the conditional
block?
?php
$_SESSION['Request'] = Request::getInstance();
if ($_SESSION['Request']-isRefresh() ) {
$_SESSION['Request']-saveToSession();
/* etc. */
exit();
}
/* Rest of script follows here */
?
IMHO the point of OOP is to keep each function split into the minimal
functionality that you need. This allows you to reuse code easier
because a function does only the *minimum* amount of work necessary
instead of extra (unintended) functionality.
2) must provide mechanism for generating per session uniqe request
identiers. now implemented as md5($_SESSION[next_reqest_id]++) not very
effective but handy:-P
The default session IDs aren't unique enough for you? Well then you can
use uniqid()
?php $sess_id = md5(uniqid(rand(), TRUE)); ?
3) must be serializable (this is why i can not put that session manipulation
at __sleep function)
these requirements (1,3) cast out __destruct, __sleep and explicit call to
some saveToSession function. do You have any other idea when to store this
information , please?
So... Request must be serializable? Forgive me but I don't see how this
is a problem. Perhaps someone else will understand what you mean here.
Do you mean that you need to serialize Request when condition in #1 is
true? If that's the case then you should be able to use the code block
above.
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
*doh* i don't know how could i coverlooke taht user reaction:-( thank You.
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
Isn't __destruct is called even if reference count is gr then zero as a part
of script finalization? imo yes -- i tried this with echoing something
within singletons destructor (no invoke with explicit delete:-) and it
worked.
BR
a3c
Yes, __destruct() gets called as part of the script finalization and
depending on your needs this might or might not be A Good Thing.
--
Teach a man to fish...
NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-generalw=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
LAZY |
http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins
signature.asc
Description: OpenPGP digital signature
