[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/ ## ####
Re: [cgiapp] authentication and authorization callbacks
On Tue, Nov 06, 2012 at 03:32:13PM -0500, Mark Stosberg wrote:
You call init in BUILD, but then explicitly run down the callback list in
the run() method. What I am wondering is if you could bridge the gap to the
other side that would allow one to munge around with the *ordered contents
of %CLASS_CALLBACKS.
my %CLASS_CALLBACKS = (
# hook name package sub
init = { 'PSGI::Application' = [ 'init'] },
prerun= { 'PSGI::Application' = [ 'prerun' ] },
# for example, add
authentication = { 'My::PSGI::Application' = [ 'authentication' ] },
authorization = { 'My::PSGI::Application' = [ 'authorization' ] },
postrun = { 'PSGI::Application' = [ 'postrun' ] },
teardown = { 'PSGI::Application' = [ 'teardown'] },
load_tmpl = { },
error = { },
);
Instead of me having to reimplement the run() method to provide for custom
top level callbacks, would it be possible to craft run() so that it took
%CLASS_CALLBACKS as ordered (e.g., if %CLASS_CALLBACKS was tied with
Tie::Hash::Indexed) ?
Right now, it seems like I'd have to reimplement the run(), when all I
really wanted
to do was insert top level callback classes wrt the order in which they are
run.
Brett, I think this existing functionality would provide what you want:
PSGI::Application-new_hook('authorization');
PSGI::Application-add_callback('authorization', \callback);
Kind of, but what it doesn't allow me to do is affect the order in
which the lifecycle hooks are executed. I think that I would also
have to make a -call_hook('authorization'), when what I really want
to do is not only create the 'authorization' hook, but add it as a
bona-fide lifecycle event like 'init', 'prerun', etc and choose at
what point after 'init' is executed.
That would register a hook named 'authorization', and register a
callback to fire the same as it would as if it were in the built-in hash.
Or have I misunderstood the request?
You're close.
If need-be, we could make %CLASS_CALLBACKS, replaceable, but I want to
be first be clear that there's a need.
That's really a subjective call, and not mine to make. I think that
ultimately it'd be nice to be make the run() method general enough to
where you can have a custom hook executed there in an order of your
choosing, without having to call -call_hook('foo') explicitly in your
PAP instance.
So, maybe something like this:
PSGI::Application-new_hook('authorization','before','prerun');
PSGI::Application-add_callback('authorization', \callback);
Then run() would know due to some ordered notion of the default hooks
that -call_hook('authorization') would effectively get called
'before' the 'prerun' hook.
I think of the hooks as stacks that contain registered callback
methods. You get 'init', 'prerun', etc for free. And yes, you can
create your own stack and registered callbacks to them. However,
sometimes it would be really convenient if you could insert your own
custom hook into the list of those that are implicitly called - it
might particularly make it easier for plugins to better manage when
and what they execute.
Ultimately, I just want a way to create my own top level hook
and not have to -call_hook when I could just slide it into the
lifecycle of events itself.
Thanks for your consideration.
Brett
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/ ##
####
--
# 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] authentication and authorization callbacks
Brett, I think this existing functionality would provide what you want:
PSGI::Application-new_hook('authorization');
PSGI::Application-add_callback('authorization', \callback);
Kind of, but what it doesn't allow me to do is affect the order in
which the lifecycle hooks are executed. I think that I would also
have to make a -call_hook('authorization'), when what I really want
to do is not only create the 'authorization' hook, but add it as a
bona-fide lifecycle event like 'init', 'prerun', etc and choose at
what point after 'init' is executed.
I see the difference. You still want the ability to decide where within
run the hook point is fired from.
So, maybe something like this:
PSGI::Application-new_hook('authorization','before','prerun');
PSGI::Application-add_callback('authorization', \callback);
Then you need one more piece:
before 'prerun' = sub {
my ($self,@args) = @_;
$self-call_hook('authorization', @args);
}
before is a method modifier provided by Moose and Mouse. Since
PSGI::Application uses Any::Moose, it will always be available for use.
The pieces can be wrapped up in an Authorization plugin for those who
want to use it.
Once that's done, there's no more calling call_hook() explicitly, just
use the authorization plugin.
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/ ##
####
