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.


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

Reply via email to