On Thu, May 22, 2014 at 10:55 PM, Warren Young <war...@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-unsubscr...@perl.apache.org > > For additional commands, e-mail: asp-h...@perl.apache.org > >