On 5/21/14 11:45 PM, Tsirkin Evgeny wrote:
It has been a while.
Josh it is great you a here .
Thanks, its good to be back!
After Warren took the time to compare Dancer to Apache::ASP i had to look into
the framework.
Just read the Cookbook .
It seems like the Dancer is following the famous MVC/Ruby on Rails where it can.
Routing,Layouts,DSL (OK ,Ruby is a DSL in a way by itself).
Apache::ASP is more like php in old days ,put a page and it will work.
KISS! I love things that just work too!
I still think that Apache::ASP has it's place.Not just for legacy.
Putting a .asp file and have it work is an advantage.
It is a good idea to have a module/method be called with routing.
I know I miss it a lot for AJAX and data processing requests.
You know I have not much followed the routing paradigms. To me it seems that
this would be an area I would have solved with a mod_rewrite or a mod_perl
handler, changing up the URL destination on the back end. But that is old
school me. I wonder if Apache::ASP were to be made to work with something like
Plack, if it would pick up some routing potential on the way (or maybe just a
Plack way of doing things?)
The most problem with Apache::ASP for by now is that it is tied to mod_perl
with it's module reloading ,memory hogging problems.
Yes, always been a problem, but memory is so cheap! :)
It used to be that throwing up a mod_proxy in front of mod_perl was the best way
to limit the memory issues (as well as some preload of Apache::ASP in the parent
httpd process), but these days it seems that having an nginx in from of a
mod_perl apache would be better, and limit the # of processes there.
So I will be glad to invest some time in helping porting Apache::ASP and
introduce whatever is missing ,at least for me.
Evgeny
Thanks!
Josh
On Thu, May 22, 2014 at 2:52 AM, Josh Chamas <j...@chamas.com
<mailto:j...@chamas.com>> wrote:
Thanks Warren for the write up! Sounds pretty exciting going full on into a
new framework and having that stick even better.
I built Apache::ASP back in the day when both PHP and Java were toys (even
Linux was half baked), and glue of the web and unix systems was often perl,
my first love of a language. Its all gotten a bit more evolved since then
to say the least. :)
& thanks for hanging out these past years on the list!
Cheers,
Josh
On 5/21/14 4:42 PM, Warren Young wrote:
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 <http://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-unsubscribe@perl.apache.__org
<mailto:asp-unsubscr...@perl.apache.org>
For additional commands, e-mail: asp-h...@perl.apache.org
<mailto:asp-h...@perl.apache.org>
------------------------------__------------------------------__---------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.__org
<mailto:asp-unsubscr...@perl.apache.org>
For additional commands, e-mail: asp-h...@perl.apache.org
<mailto:asp-h...@perl.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org
For additional commands, e-mail: asp-h...@perl.apache.org
