It has been a while.
Josh it is great you a here .
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.
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.
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.
So I will be glad to invest some time in helping porting Apache::ASP and
introduce whatever is missing ,at least for me.
Evgeny
On Thu, May 22, 2014 at 2:52 AM, Josh Chamas <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) 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
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org
> For additional commands, e-mail: asp-h...@perl.apache.org
>
>
