Re: [cgi-prototype-users] persistent prototypes (mod_perl)

[Ryan Tate]

Randal L. Schwartz  wrote:


Another way would be to put all your slots into one big "per hit" slot,
and then ensure that this is cleared out:

sub My::App::app_enter {
 my $self = shift;
 $self->reflect->addSlot(per_hit => {});
}



I like this approach quite a bit.

After reading your message, though, I got a bit greedy and decided I 
wanted to be able to add slots rather than just hash entries to per_hit, 
so I could do cool things like autoload fields and coderefs that you don't 
have to know are coderefs.


Then I got a bit lazy and decided I did not want to edit all my templates 
to change things like "[% self.user %]" to "[% self.per_hit.user %]".


So I decided to extend your idea a bit to the following:

sub My::App::app_enter{
  my $self = shift;
  my $per_hit = Class::Prototyped->new;
  $self->reflect->addSlots( 'per_hit*' => $per_hit,
per_hit => $per_hit );
}

I went through my classes and changed most every ->reflect->addSlots
to ->per_hit->reflect->addSlots, and things seem to be working fine. At 
least, nothing has blown up yet ;->


I double-checked to make sure the 'per_hit*' parent classes were not 
accumulating on top of one another, one for each hit. As I 
suspected, writing a parent slot with the same name as 
a previously-established parent slot seems to overwrite it.


One problem with this approach is that almost every slot I create seems to 
be per_hit. I'm starting to think it would be smarter to create a 
'persist*'/'persist' slot in the manner above, then in control_leave 
iterate over 
the slots and delete each one except 'persist'. This may be time consuming,

however.

RT


---
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

Re: [cgi-prototype-users] persistent prototypes (mod_perl)

[Randal L. Schwartz]

> "Ryan" == Ryan Tate <[EMAIL PROTECTED]> writes:

Ryan> Hello,
Ryan> I recently moved a simple CGI::Prototype-based Web app over to a
Ryan> mod_perl2 installation. It wasn't too hard.

That's good to hear.  I tried to design CGIP with mod_perl in mind,
but I had no current customers using mod_perl directly.

Ryan> One thing I eventually noticed: if you dispatch to objects
Ryan> representing particular classes, as CGI::Prototype::Hidden does (see
Ryan> name_to_page and its call to $package->reflect->object), you have to
Ryan> be careful to re-initialize slots as needed, because package objects
Ryan> are not garbage collected and thus will persist.

Yes.  And this can be trouble, as you've seen.

Ryan> To handle initialization, for each class with slots I want killed
Ryan> before the next request, I do a control_leave with
Ryan> $self->reflect->deleteSlots(qw(userfoo userbar tempfoo tempbar)),
Ryan> along with $self->SUPER::control_leave(@_) for any classes above.

That would seem to be the logical place to do this.

Another way would be to put all your slots into one big "per hit" slot,
and then ensure that this is cleared out:

sub My::App::control_enter {
  my $self = shift;
  $self->reflect->addSlot(per_hit => {});
}

Through testing, I see that addSlot also throws away any previous
meaning for the slot, so this trashes the previous round data just
fine.

Then in any thing that needed it:

sub randomfunc {
  my $self = shift;
  my $per_hit = $self->per_hit;

  $per_hit->{foo} = "bar";
}

In this case, you just need to keep your keys of $per_hit clean,
but you had to do that with slots anyway. :)  This'll also be faster
than adding and deleting slots every time.

Ryan> PS Liked the first Linux Mag article.

Parts two and three coming up... :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


---
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