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-general&w=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=PHP&submitform=Find+search+plugins
Attachment:
signature.asc
Description: OpenPGP digital signature
