On 5/20/2014 13:06, Josh Chamas wrote:
So where does this put you in the consideration of platform migration
etc? Plack, Mason, TT, etc.
Shortly after I started this thread, I decided to just try one of the
alternatives, for education value if nothing else.
I narrowed my options to Dancer and Mason+Poet, as those are the only two
popular, full-featured, actively-developed Perl web frameworks that still run
under Perl 5.8, which we're going to have to support for years yet. Mojolicious
and Catalyst are the other main options, and they both require 5.10.
Mason is functionally quite similar to Apache::ASP, whereas I'd say less than
50% of Dancer directly maps to the ASP way of doing things. Nevertheless, I
decided to start with Dancer purely because it has a more active mailing list.
I told myself that I would fall back to Mason if the Dancer experiment fizzled.
As it turned out, Dancer delivered in spades, so I never did spend any time with
Mason+Poet.
About the only things in Dancer that map 1:1 to Apache::ASP -- or near enough
that simple regexes can fix up most of the differences -- are the Request,
Response and Session objects.
Dancer differs from Apache::ASP in pretty much every other way:
- There is no direct equivalent of Apache::ASP's Application and Server
objects. The features are all present in Dancer, but not collected together in
the same way. For example, $Server->Config('foo') is config->{foo} in Dancer.
(As a rule, Dancer function and object names are shorter than in Apache::ASP.
For another example, $Request->QueryString('foo') is param 'foo' in Dancer.)
- Dancer's API is a DSL rather than idiomatic Perl as in Apache::ASP. This
bothers to about the same extent that <script> blocks in an HTML file bother
me. Bouncing between languages adds a context switch while reading code; it's
worst when you have blocks of code that fill a screen, so that you have to
remember context of language A across a screenful of language B.
Apache::ASP can't throw stones, though, due to the mixing of Perl and HTML in
*.asp files. It's easier to wrap the Dancer DSL in a Perlish API than it is to
avoid Perl code in *.asp files.
- Apache::ASP's URL handing is file-based. That is, the mere existence of
$webroot/foo.asp means http://server/foo.asp is a legal URL. Dancer, like many
newer frameworks, has a route-based URL system, meaning that you define your
dynamic URL hierarchy in code, rather than in the filesystem. (Static resource
files are still mapped directly to URLs in Dancer, of course.)
The files your route handlers use to fulfill each request is entirely up to the
you. Some kind of straightforward 1:1 mapping (e.g. /foo/bar uses
views/foo/bar.tt) is sensible, but not by any means required.
- Dancer encourages you to separate your GET and POST handlers into separate
routes, whereas with Apache::ASP, the path of least resistance is to put them
both in the same file, for much the same reason that CGI scripts have GET and
POST handling in the same file. You end up with stuff like:
if ($Request->{Method} eq 'POST') {
# Examine $Request->Form to figure out what kind of POST it is,
# extract data from the form data, process it, etc.
}
else {
# Do something entirely different for GET
}
# Render page, either a fresh one for the GET case, or a response to
# a form submission in the POST case.
Separating your POST and GET routes reduces at least one indent level, and keeps
mostly-unrelated code separate. It also works better with Ajax-based code,
since GET usually returns HTML, whereas POST will more likely return JSON.
- Dancer has built-in automatic data serializers for several common formats:
JSON, XML, YAML, Data::Dumper...
This is great for Ajax code since:
return {
foo => 'some value',
bar => ( 'a', 'set', 'of', 'other', 'values' ),
}
...serializes naturally to a JSON object. My Apache::ASP pages that returned
JSON had to manually set Content-Type and manually call JSON::encode_json() to
serialize my Perl objects for return from Ajax handlers.
- Dancer offers many different templating systems, whereas Apache::ASP offers
just the one. Only one of the templating systems with a Dancer adapter on CPAN
-- Mason -- works anything like the ASP templating language, in that it allows
you to freely intermix HTML and Perl. I initially tried using Dancer + Mason to
minimize the amount of work needed to translate my ASP code, but after running
into some difficulties I switched to Text::Xslate, and got hooked.
Systems like Xslate force you to collect all of the Perl code to build a page
into one location, and write the template as a separate file. This makes both
the Perl and template code clearer, since you're not visually jumping back and
forth between languages, as touched on above.
Template systems like this get you a lot of the benefits of the MVC paradigm
without trying to hammer your square app into the round MVC hole.
(That's another reason I rejected Catalyst, by the way. My app really only has
Views. The closest thing to a Controller is the back-end server, written in
C++. There's a Model, but the Perl code doesn't talk directly to it through a
framework-mandated DBI/ORM scheme; in my app, the Model is hidden behind an
application server. MVC web frameworks assume M, V, and C are all in Perl, or
at most one hop away such as a MySQL DB via DBI. Both Apache::ASP and Dancer
(and Mason for that matter) are policy-free frameworks, not prescribing specific
ways of building your app.)
I tell you all this because what happened is that after climbing the initial
learning cliff, I didn't run into any serious trouble. Dancer just kept
delivering. Every time I tried porting over another tricky part of the web app,
it was just as easy to get it working with Dancer as with Apache::ASP, and often
the result was easier to understand.
I don't say this to disparage Apache::ASP. It's a fine framework, and did the
job for us for a dozen years. For that, Josh, I thank you.
The thing about Dancer is that it's simply based on a more modern, more mature
design. Separation of concerns, multi-level logging, web stack independence
thru PSGI/Plack, etc.
Because I kept failing to run into a wall with Dancer, and because the future of
mod_perl looks so uncertain -- certainly on RHEL out of the box -- I just kept
translating more and more pieces of my app. It's now running flawlessly. The
code is far clearer, partly because of the mature Dancer design, but also
because the forced refactoring made me look at code I hadn't touched in years
and bring it up to date.
Our new version is also faster, in large part because for our app, a single
long-lived application process has no downsides worth mentioning. We don't need
parallel dynamic code generation, since our app rarely has even 100 simultaneous
users per site, and those are mostly idle all the time. Thus, the only thing
that really needs to be parallelized is the static content, which is readily
done with Apache + mod_proxy or nginx.
Because of that, we can use fast in-memory sessions, we don't need a bunch of
heavy Apache children hanging around and getting re-created every 500 conns, our
back end app server connections can stay up as long as the session stays up,
etc.
I therefore say with fondness and a tinge of regret, "So long, and thanks for
all the fish."
I will remain subscribed, since this is a low-volume list. I may be able to
continue helping others with Apache::ASP. For myself, though, I'm a convert.
All new code will be in Dancer.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org
For additional commands, e-mail: asp-h...@perl.apache.org
