[cgiapp] draft version of "PSGI::Application" and load_tmpl replacement

[Mark Stosberg]

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