Re: [Catalyst] RFC: Catalyst::Controller::RHTMLO
On Mon, Feb 2, 2009 at 7:59 PM, Jason Gottshall jgottsh...@capwiz.com wrote: Zbigniew Lukasiak wrote: Maybe I am just being lazy now - but before I start digging too deep - did you take into accout that some forms require loading stuff from the DB? It can happen in to cases: 1) loading SELECT choices lists - this one is easy - because it can be done at initialisation as it does not depend on th request. 2) loading related forms for one to many relations - where you don't know how many related forms you need until you have the main object - i.e. until request time. See Rose::HTML::Form::Repeatable. Yes, I'm actually thinking of doing my $form = $class-new( app = $c ); so that the form can access model-related stuff as necessary. (This is safe because RHTMLO automatically weakens any value passed to -app). Would something like that address your cases? Hmm - I thought you mentioned something about caching the form objects between requests? Passing $c to the creator means you create the forms on per request basis. If you like the caching idea - then what would be needed is a kind of two phase initialisation. First you create a prototype - and then you add the necessary repeatable sub-forms on per request basis to it (of course this is only needed if you use repeatable sub-forms). Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI
On Mon, Feb 02, 2009 at 05:09:21PM -0600, Andrew Rodland wrote: Attached is a patch that does an srand in each child immediately after invoking pm_manage, if we are running our own process manager. applied to 5.80/trunk as r9178. -- BOFH excuse #147: Party-bug in the Aloha protocol. signature.asc Description: Digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: Catalyst::Controller::RHTMLO
Zbigniew Lukasiak wrote: On Mon, Feb 2, 2009 at 7:59 PM, Jason Gottshall jgottsh...@capwiz.com wrote: Zbigniew Lukasiak wrote: Maybe I am just being lazy now - but before I start digging too deep - did you take into accout that some forms require loading stuff from the DB? It can happen in to cases: 1) loading SELECT choices lists - this one is easy - because it can be done at initialisation as it does not depend on th request. 2) loading related forms for one to many relations - where you don't know how many related forms you need until you have the main object - i.e. until request time. See Rose::HTML::Form::Repeatable. Yes, I'm actually thinking of doing my $form = $class-new( app = $c ); so that the form can access model-related stuff as necessary. (This is safe because RHTMLO automatically weakens any value passed to -app). Would something like that address your cases? Hmm - I thought you mentioned something about caching the form objects between requests? Passing $c to the creator means you create the forms on per request basis. If you like the caching idea - then what would be needed is a kind of two phase initialisation. First you create a prototype - and then you add the necessary repeatable sub-forms on per request basis to it (of course this is only needed if you use repeatable sub-forms). Yeah, I gave up on caching for now, mostly due to concerns about form mutability. And it's a premature optimization that will be harder to code for given the other factors I'm dealing with, so I don't want to think about it yet. The example you cite raises precisely one of my concerns: if you start with a cached prototype form and add subforms per-request, you have to make sure you include some sort of cleanup or reset routine to clear out the temporary subforms from the previous request. By extension, many various temporary modifications to the form structure (other than merely adding subforms) are possible, so we'd need to develop some kind of generic mechanism for removing these modifications. My brain isn't ready to tackle that problem right now, so I'm blissfully ignoring it :-) -- Jason Gottshall jgottsh...@capwiz.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI
On Tuesday 03 February 2009 11:45:07 am Jonathan Rockway wrote: * On Mon, Feb 02 2009, Andrew Rodland wrote: I've thought over the problem and decided that the only appropriate place for a fix is in Engine::FastCGI. A srand anyplace else (including the app code) would run either too early (not solving the shared state problem) or too late (re-seeding on every request is Bad.) Wait, is there a reason why we can't do this in FCGI::ProcManager instead? This is something that affects everyone using FCGI, not just Catalyst. A reasonable question. I'll see if I can get gbjk's thoughts on the matter. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
