Re: [cgi-prototype-users] Lazy compilation for the render class in CGIP::Hidden
> "Harald" == Harald Joerg <[EMAIL PROTECTED]> writes: Harald> That's what I like with CGIPH: The code is so slim that it is pretty Harald> easy to understand, hence rather riskless to overload, and TIMTOWTDI! Thanks! That was the point. Do just the basics. Don't go nutty. Add things as you see fit when they are common to *all* apps. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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! - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] Lazy compilation for the render class in CGIP::Hidden
On 10/25/07 10:32 AM, "Harald Joerg" <[EMAIL PROTECTED]> wrote: > Writing an extra mantra $self->name_to_page() dozens of times (in > every respond, every module) is sightly annoying and gives me the > impression of a decentralized workaround. Actually, I just look at it as useful refactoring. We actually have situations in some of our applications where we cross over application classes between respond and render; i.e. The response of App1::page_x may want to return App2::page_y at times. So simply passing the name of the page isn't enough, we really need to return a page object with an explicit full class name. It definitely makes sense to localize the functionality you need, but rolling that up into CGI::Prototype would make it less flexible. > If I write another application, which may be not before next year, I > am sure to stubmle over that again. It is not in the Linux Mag > examples, not easily collected from the PODs, and not in my own > mod_perl apps. Better documentation would make this easier to understand. I reckon Randal has written enough of the basic stuff and its up to us as a community to put together some more in-depth tutorials. That said, I'm not exactly swimming with spare time :) Maybe come late December early January (winter break) I'll have some time to work on something collaboratively. Perhaps a CGIP wiki would be a good option. Andrew -- Andrew Gianni - Lead Programmer Analyst Administrative Computing Services / Computing and Information Technology University at Buffalo, State University of New York 215 Millard Fillmore Academic Complex, Buffalo, NY 14261-0026 716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] Lazy compilation for the render class in CGIP::Hidden
Andrew Gianni <[EMAIL PROTECTED]> writes: > On 10/25/07 5:31 AM, "Harald Joerg" <[EMAIL PROTECTED]> > wrote: > >> sub respond { >># ...du whatever needs to be done in response to the user's request >>return 'NextPage'; >> } > > Try: > > sub respond { >my $self = shift; >return $self->name_to_page('NextPage'); > } > > Or is there some specific reason that you want to just return a string > instead of an object? Yes, of course I could do that, and there is no specific reason other than DWIM. Writing an extra mantra $self->name_to_page() dozens of times (in every respond, every module) is sightly annoying and gives me the impression of a decentralized workaround. If I write another application, which may be not before next year, I am sure to stubmle over that again. It is not in the Linux Mag examples, not easily collected from the PODs, and not in my own mod_perl apps. Currently I've flipped to overriding activate in My::App.pm., and inserted the autoloading code immediately before the call to $next_page->control_enter. For the moment, I like it that way :-) That's what I like with CGIPH: The code is so slim that it is pretty easy to understand, hence rather riskless to overload, and TIMTOWTDI! -- Cheers, haj - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] Lazy compilation for the render class in CGIP::Hidden
On 10/25/07 5:31 AM, "Harald Joerg" <[EMAIL PROTECTED]> wrote: > sub respond { ># ...du whatever needs to be done in response to the user's request >return 'NextPage'; > } Try: sub respond { my $self = shift; return $self->name_to_page('NextPage'); } Or is there some specific reason that you want to just return a string instead of an object? Andrew -- Andrew Gianni - Lead Programmer Analyst Administrative Computing Services / Computing and Information Technology University at Buffalo, State University of New York 215 Millard Fillmore Academic Complex, Buffalo, NY 14261-0026 716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users