Hello,
I recently moved a simple CGI::Prototype-based Web app over to a mod_perl2
installation. It wasn't too hard.
One thing I eventually noticed: if you dispatch to objects representing
particular classes, as CGI::Prototype::Hidden does (see name_to_page and
its call to $package->reflect->object), you have to be careful to
re-initialize slots as needed, because package objects are not garbage
collected and thus will persist.
To handle initialization, for each class with slots I want killed before
the next
request, I do a control_leave with $self->reflect->deleteSlots(qw(userfoo
userbar tempfoo tempbar)), along with $self->SUPER::control_leave(@_) for
any classes above.
If you fail to re-initialize your slots, they persist to the next hit,
which is a feature if you know what you're doing and a bug otherwise. I
have not yet found it useful to persist any slots.
I am curious if name_to_page was made with an eye toward mod_perl -- was
it foreseen that in a persistent environment one might need to initialize
slots? I'm wondering if a better approach might be to make my own
name_to_page that does $package->new, thus not requiring any
initialization, but costing more (probably) in obj creation and requiring
extra work to keep track of shortname (essentially page_to_name to
remember what state name/package was used to gen the object).
I have not yet found any slots I wish to persist so I end up having to
remember to write an initializer for each slot I create.
Cheers
RT
PS Liked the first Linux Mag article.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
