[cgiapp] draft version of PSGI::Application and load_tmpl replacement
Ron, Thanks for all the feedback. Follow-ups are below. * query() is now req() and new(QUERY=...) is now new(REQUEST=...) I'd go with request(). I see no need to introduce an abbreviation. For reference: Catalyst uses both request() and req() Mojolicious uses only req() Dancer uses only request() Amon2::Web uses both request() and req() My inclination is to start with just one, 'req()' and consider adding the alias later. Having just one keeps all the code samples consistent. * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. * The default request object has changed from CGI.pm to CGI::PSGI Excellent. I would really prefer something closer to Plack::Request, but don't feel like there's an obvious path forward for this piece yet. * forward() and redirect() are now in the core. Excellent. I think it's forward() that still contains some shim-code specific to the AutoRunmode plugin. That be nice if it wasn't required in the core, but I haven't looked closely at the implications of removing it. * load_tmpl() and html_tmpl_class() have been removed Here's some more thought on what might replace them: First, from a survey of other frameworks and modern templating options, the attractive ones all use a API design that goes like this: Template params are accumulated in a stash in the framework, and then provided to a render method when the template is rendered. Systems that work like this include: * Catalyst * Mojo * Dancer * Text::Xslate (up and coming templating solution gaining popularity) * Tiffany (Like DBI for templates, based on a standard from Ruby called tilt) * Template Toolkit (including the popular TT plugin for CGI::App) Of course, we don't need use the API just because it's popular. However, I've found some good reasons for this design that are worth supporting: * The design with load_tmpl()/param()/output() ties us to the API for HTML::Template. This API is flawed because because in the constructor, it mixes the file name (which changes) in the with the configuration data (which is static). More modern options (as well as TT) use new() exclusively for configuration options. This API is friendly for framework integration, where you would store your configuration details somewhere out of sight and separate from loading files. * Ideally, the View phase of MVC would be separate from the Controller phase. This gives you greater flexibility in controlling the output format. Say, returning the data structure as JSON or XML instead of HTML. When we use load_tmpl() and $t-param() throughout our code, we are interleaving the View phase with the controller phase. So, one option is use stash() and render() methods to support templating. Amon2::Web handles this with two methods: create_view() -- supply an object with a render() method render() -- call the render method on the object above. That solution doesn't also look in a stash, but it would be easy add. This simple API is a natural fit for the Tiffany protocol, and there any many tempating engines which support that, either redirectly or through a shim, so we wouldn't have to invent yet-another view abstraction system. That's attractive to me. https://metacpan.org/module/Amon2::Web https://metacpan.org/module/Tiffany Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. -Kurt # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 11/06/2012 12:27 PM, Kurt Lidl wrote: On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. I am looking for feedback. Thanks for the opinion. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 6/11/2012 8:36 μμ, Mark Stosberg wrote: On 11/06/2012 12:27 PM, Kurt Lidl wrote: On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. I am looking for feedback. Thanks for the opinion. Mark Hello... IMHO, there should be no enforcement. If that was a convention I suggest to keep it like this. Conventions play well with TIMTOWTDI, too... A discussion on the convention would be ok, but I believe that such enforcements are not really necessary. Documentation can suggest the convention. This is my opinion, if I'm not missing something... +1 for the rest of the API changes. Giannis # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 11/06/2012 01:55 PM, Giannis Economou wrote: On 6/11/2012 8:36 μμ, Mark Stosberg wrote: On 11/06/2012 12:27 PM, Kurt Lidl wrote: On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. I am looking for feedback. Thanks for the opinion. Mark Hello... IMHO, there should be no enforcement. If that was a convention I suggest to keep it like this. Conventions play well with TIMTOWTDI, too... A discussion on the convention would be ok, but I believe that such enforcements are not really necessary. Documentation can suggest the convention. This is my opinion, if I'm not missing something... Thanks for the feedback. +1 for the rest of the API changes. Thanks for the endorsement! Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
