where/how to dump the garbage in ZF? diy, or somewhere 'in there' already?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

where/how to dump the garbage in ZF? diy, or somewhere 'in there' already?

OpenMacNews-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi all,

(since Cal's apparently counting, though i'd fire off 'another one'... ;-)

i'm looking for where to best grab session status & act upon destroying
object-related resources.  not garbage collection of objects themselves,
per se, but of related files.

simple e.g.: i've got a class that dynamically generates image-based
rollover menus.  menu item images are created & written to disk on
demand @ session_id-named dirs.  those images are relvant only for the
duration of the session.  after the session terminates (cleanly or
otherwise), the menu objects themselves are gc'd ok by the destructor,
but i want to delete those files/dirs as well.

i presume one approach is the queue up the object IDs in a session
stack, and conditionally manage them in the controler itself (?).

so where in a ZF front-controller-based pattern will/is/should such
garbage-related collection be managed?

my naiive suspicion is that, currently, it's DIY, and that some
combination of Zend_Session & Zend_Cache (i'kk evtually figure out the
'right' balance between Zend_Cache-to-be, eA & memcached ... ugh) will
be involved ... but i'm guessing.  a grep -i on 'garbage' in src tree
returns null ... :-/

thoughts?

thanks!

richard

- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iEYEAREDAAYFAkRr1ssACgkQlffdvTZxCMascwCfQamkpEaoHQaQ2UBh3EUnPCLg
6YoAoK+JIrEmJDxZAG6b79OS+g56hXyC
=pcj0
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: where/how to dump the garbage in ZF? diy, or somewhere 'in there' already?

Steven Van Poeck
OpenMacNews a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> hi all,
>
> (since Cal's apparently counting, though i'd fire off 'another one'... ;-)
That doesn't mean you have to send the message three times :p

>
> i'm looking for where to best grab session status & act upon destroying
> object-related resources.  not garbage collection of objects themselves,
> per se, but of related files.
>
> simple e.g.: i've got a class that dynamically generates image-based
> rollover menus.  menu item images are created & written to disk on
> demand @ session_id-named dirs.  those images are relvant only for the
> duration of the session.  after the session terminates (cleanly or
> otherwise), the menu objects themselves are gc'd ok by the destructor,
> but i want to delete those files/dirs as well.
>
> i presume one approach is the queue up the object IDs in a session
> stack, and conditionally manage them in the controler itself (?).
>
> so where in a ZF front-controller-based pattern will/is/should such
> garbage-related collection be managed?
>
> my naiive suspicion is that, currently, it's DIY, and that some
> combination of Zend_Session & Zend_Cache (i'kk evtually figure out the
> 'right' balance between Zend_Cache-to-be, eA & memcached ... ugh) will
> be involved ... but i'm guessing.  a grep -i on 'garbage' in src tree
> returns null ... :-/
My suspicion too is that it is DIY using the PHP5 native __destruct()
function, as Terry says...
>
> thoughts?

I'm thinking out loud here, but IMO it might be useful to have a wrapper
for this, so that you can "store" pointers to all objects (or items for
that matter) you want to deliberately destroy upon session/script ending.

On the other hand, is it really up to the Framework to provide such
methods ? Should these things not be handled through application
logic/methods ?

Steven Van Poeck
http://svanpoeck.free.fr/blog/tech/

>
> thanks!
>
> richard
>
> - --
>
> /"\
> \ /  ASCII Ribbon Campaign
>  X   against HTML email, vCards
> / \  & micro$oft attachments
>
> [GPG] OpenMacNews at gmail dot com
> fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iEYEAREDAAYFAkRr1ssACgkQlffdvTZxCMascwCfQamkpEaoHQaQ2UBh3EUnPCLg
> 6YoAoK+JIrEmJDxZAG6b79OS+g56hXyC
> =pcj0
> -----END PGP SIGNATURE-----
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: where/how to dump the garbage in ZF? diy, or somewhere 'in there' already?

OpenMacNews-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi steven,

>> That doesn't mean you have to send the message three times :p

hrm? three times?  i know gmail was having some issues, reporting server
problems, and TBird was retryting ... bud didn't think it went thru but
once. sorry :-|

>> My suspicion too is that it is DIY using the PHP5 native __destruct()
>> function, as Terry says...

yup.

>> I'm thinking out loud here, but IMO it might be useful to have a wrapper
>> for this, so that you can "store" pointers to all objects (or items for
>> that matter) you want to deliberately destroy upon session/script ending.

which is the approach i'm simply using ... works fine. but, diy, of
course. currently storing the stack in a session array ... could be the
zf $view object, i suppose, too ...

>> On the other hand, is it really up to the Framework to provide such
>> methods ? Should these things not be handled through application
>> logic/methods ?

per my last response to terry, not completely clear to me where in mvc
generally, or zf specifically, it can/should happen ...


cheers,

richard

>
> --
>
> /"\
> \ /  ASCII Ribbon Campaign
>  X   against HTML email, vCards
> / \  & micro$oft attachments
>
> [GPG] OpenMacNews at gmail dot com
> fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
>>
>>
>>
>>

- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iEYEAREDAAYFAkRstDQACgkQlffdvTZxCMZQXQCdFoLYsUw00Y847HBk647RFCx0
kLEAoJL9UHBquSBku8NLUIRiDUCWy5+c
=oGjR
-----END PGP SIGNATURE-----