On 2005-12-08, Rhesa Rozendaal <[EMAIL PROTECTED]> wrote:
>
> Ok, now that you all have had time to play with this, please explain why this
> is less difficult and unwieldy than mod_rewrite.
>
> Seriously.
>
> Another question: how is this at all relevant for cgiapp? Why should my apps
> care about urls? All they need to know is that input comes through
> $self->query->param, and output goes through $outputref in cgiapp_postrun.
>
> Thirdly: Links belong in my templates, not in my app, so I have no business
> knowing how to generate them.
Traditionally, web applications got all their variables in URLS through
query strings.
Jesse was the first person I recall advocating something different:
putting the run mode in PATH_INFO. This made a lot of sense because it
seperated the /state/ of the application from the rest of the form data
being transmitted. Later, processing a run mode this way became a
built-in feature of CGI::Application.
I've seen a lot of CGI::App based websites using this "script.cgi/rm"
style. Although it's rather useful, I hadn't see this much on on
websites outside of CGI::Application.
I think CGI::App users used this because it was *easy*, as well as
providing value.
Now I see that nearly all Rails apps seem to be using the
:controller/:action/:id model.
It seems clean and useful, yet I don't see it much outside of Rails.
mod_rewrite has been around for ages as a known technology, yet I can
no popular standard mod_rewrite solutions that are being used to solve
this problem. Drupal uses a bit of mod_rewrite as part of standard
setups, but only enough to pass everything to Drupal's own dispatcher.
I believe the difference in Rail's success of having clean URLs (versus
mod_rewrite verus The World) is that they made it *easy* and *standard*.
In our own system, I foresee a helper script that would set up standard
bits for a website:
$cape newsite .
Adding Scaffolding...
www/cgi-bin/dispatch.cgi
www/.htaccess
config/dispatch.pl
config/Config.pl
perllib/
t/pod.t
While this is just a sketch, it gives you idea that right off the bat,
you could be starting with a .htaccess file that filters everything to a
dispatch script, and all you have to do is edit a configuration file,
using Perl, a tool you already know well.
Without the Apache requirement, it becomes easier for people to work
offline one laptops-- people like the built-in server in Catalyst for
this reason.
> Why is every framework reinventing the same wheel over and over again?
The dispatcher being designer wouldn't have to be tied to CGI::App.
I imagine we can talk to equivalent of new() and run() in Catalyst.
Adapters for some other Perl-based frameworks could be made as well.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
