On Thu, May 22, 2014 at 10:55 PM, Warren Young <[email protected]> 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: [email protected]
>
> For additional commands, e-mail: [email protected]
>
>
