perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsirkin Evgeny <tsir...@gmail.com>
Subject Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Date Fri, 23 May 2014 09:45:07 GMT
On Thu, May 22, 2014 at 10:55 PM, Warren Young <warren@etr-usa.com> wrote:

>
> Routing is more than just an abstraction between the implementation level
> and the presentation to the browser.  It forces you to consider your
> logical URL structure.
>
> My Apache::ASP code just growed, like Topsy.  One page at a time, with no
> consideration of the interfaces exposed by the other pages.  There was
> consistency of design only to the extent that there was code copying, and
> then in decreasing fashion with respect to time, as the cloned pages
> diverged.
>
> As soon as I started developing a system of routes in the Dancer port, I
> realized that I had an API.  It was sitting there the whole time, never
> identified in the Apache::ASP form, but there it was in the Dancer code,
> clear as day.  Once I'd formally extracted it, I spent a day redesigning it
> the way it should always have been.  The correct design popped right out,
> obvious as a green sky.
>
> This happens because you have to describe your URL structure to Dancer,
> one URL per line.  Many fit in a single screen of text, so patterns jump
> out at you.
>
> Example in Dancer pseudocode:
>
>     get '/' => ...
>     get '/login' => ...
>     get '/logout' => ...
>
>     prefix '/app' => sub {
>         get 'page1' => ....
>         get 'page2' => ....
>     };
>
>     prefix '/api' => sub {
>         del  'foo/:id' => ...
>         get  'foo/:id' => ...
>         post 'foo' => ...
>         put  'foo' => ...
>
>         get  'bar/:id' => ...
>         ...same as foo...
>     };
>
> The story this route structure tells is clear:
>
> 1. First you go to the top level page, which perhaps has a Log In link or
> button to send you to the /login page.
>
> 2. The /login page creates a session and bounces you to /app when you log
> in successfully.
>
> 3. There's a button or link somewhere that sends you to /logout, which
> destroys your session and sends you back to / or /login.
>
> 4. The app does CRUD-y things to "foo" and "bar" objects through
> /api/{foo,bar}, creating via PUT, reading via GET, updating via POST, and
> deleting via DELETE.  GET and DELETE require a record ID to tell the
> handler what to operate on, while PUT and POST must be fairly complex in
> what they will accept, so that the parameters cannot be marked as required
> in the route structure.
>
> It's kind of like that Fred Brooks quote, "Show me your flowcharts and
> conceal your tables, and I shall continue to be mystified. Show me your
> tables, and I won’t usually need your flowcharts; they’ll be obvious."
>
>
What you describe looks much like REST.
Is it good? I don't know .I guess it is a matter of taste  .
Personally ,I like it sometimes and sometimes I wish it would just let me
do what I want and don't force to do "the right thing".

The possible problem of this approach - you need a reverse routing API.
How do you link to an action in a way that is changeable?
What if you want to change all the /app pages to sit under /app_num1 ?
ROR have a helper methods for this ,call "link " method and ROR looks into
the routing tables and creates the reverse route for you.
I guess Dancer have/should have something similar.

I think it would be better for Apache::ASP to have a minimal routing .
Let say -



>  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?)
>>
>
> I don't think so.  I believe a minimum-effort Apache::ASP Plack port would
> have only one feature relative to Apache::ASP v2, that being web stack
> independence.  From your perspective, the big difference is that you have
> to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI equivalents.
>
> To get a handle on what routing does for Dancer, say:
>
>     $ sudo cpanm Dancer
>     $ dancer -a foo
>
> This generates a complete, self-contained sample app, suitable for hacking
> on directly.  That is to say, the file and directory structure it generates
> is suitable for production use.
>
> The routing structure is in foo/lib/foo.pm.  You also use this file to
> define hooks, which are roughly equivalent to global.asa event handlers in
> Apache::ASP.  Script_OnStart is the same as Dancer's "before" hook, for
> example.  There is no direct equivalent of Session_OnStart, but you can
> build that into the "before" hook, too.  The Dancer equivalent to the
> Application_* event handlers is foo/bin/app.pl.
>
> If Apache::ASP were to get a routing system, I don't know that you'd
> necessarily want to put it in global.asa.  It works well for Dancer, but
> perhaps another design would make more sense for Apache::ASP, since
> global.asa has historical meaning.
>
> Notice, by the way, that foo/lib gets added to @INC by foo/bin/app.pl.
> This solves another problem I had with Apache::ASP, which doesn't like you
> to define functions and classes in your *.asp files.  You end up creating
> *.pm files to hold all reused and complicated code.  Where then do you put
> those *.pm files so that mod_perl can find them?
>
> In my Apache::ASP app, I ended up installing them into the system's
> site_perl directory, and then I could never remember the path to those
> files when I had to hand-hack one of these files on a production server to
> test a problem fix in the field.  With Dancer, the *.pm files are right
> there next to the rest of the app.
>
>
>  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! :)
>>
>
> I know you're joking, but RAM on VPSes isn't cheap.  4 GB more RAM in my
> colocated box is virtually free.  4 GB of RAM added to my cheap bare-bones
> VPS plan adds another $35/mo, or $420/yr, or $2,100 over the expected
> lifetime of the server.
>
> There's another advantage of Dancer.  By going with a single long-lived
> app process instead of forking off Apache children, and by making that app
> independent of tubby ol' Apache, we can squeeze our app into much smaller
> VPSes and VMs.
>
> In extreme situations, you don't even need a traditional web server. That
> "foo" app I had you create above?  It contains a perfectly usable basic web
> server, listening on port 3000.  Run it as root so it can bind to port 80
> instead or port-forward 80 to it, and you've got an entirely self-contained
> app.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
>
> For additional commands, e-mail: asp-help@perl.apache.org
>
>

Mime
View raw message