automating the creation of routes
¡Hola dancers, Like everyone else, I have been enjoying making apps per the following pattern get '/foo' => sub { my $foo1 = param 'foo1' || die 'need foo1'; my $foo2 = param 'foo2' || $default_foo2; .. }; get '/bar' => sub { my $bar1 = param 'bar1' || die 'need bar1'; my $bar2 = param 'bar2' || $default_bar2; .. }; For a number of reasons (see below), I am wondering if I could somehow generate these routes from a catalog of requisite information (resource, parameters, defaults, required or optional, and so on) held in some form of data source, most likely a database. Any ideas on how I could implement such a capability would be much appreciated. I will personally drink a beer toasting all ideas. I need a catalog of all these routes for several reasons -- 1. I have repurposed the Dancer::Plugin::SiteMap to endow all my apps with certain meta routes, one of which actually lists all the available routes (I call them resources, in keeping with the REST-compliant terminology). It works, but is kludgey. 2. I want to implement a uniform parameter validation and error/usage generation message. 3. I want to create a capability so new users can register their resources with my application and make them available to others. A central catalog of all the resources (this is a big, data integration/analysis/dissemination initiative) will make any of the above and perhaps many other needs easy to fulfill. I look forward to your as-usual-innovative suggestions. -- Puneet Kishor
Since it's all calls with subroutine references, you could implement this using loops and callbacks or closures. I generally think it's a bad idea. Over-engineering.
On Mar 7, 2012, at 10:59 AM, sawyer x wrote:
Since it's all calls with subroutine references, you could implement this using loops and callbacks or closures.
I generally think it's a bad idea. Over-engineering.
It does seem like over-engineering, and does smell of being a bad idea. However, the alternative seems just as bad. Write all the routes in the Dancer app.pm. Then, write all the routes and their parameters as rules for a validation engine. And, finally, record all the routes and their metadata (parameters, who/what/why/how) so users can get meta information about the app -- what all does this app do? Since this is a kinda data-warehousing effort (I am sure I am misusing the term data-warehousing), it is important to somehow provide this information to the users. -- Puneet Kishor
I'm not sure what your application is or does, but it shouldn't have so many routes that you would need to refactor their creation using a factory. This isn't even done in Catalyst, and clearly should not be done in something that is supposed to be *micro* like Dancer. I think what you have is, perhaps, an unwise setup of routes. For example, you could set up more generic routes that catch more situations and differ between them using variables: instead of "get '/user/view/:id' => sub { ... }", you could set up "get '/user/:action/:id' => sub { ... }" or "get '/:entity/:action/:id' => sub { ... }". Another very good way is to use chained routes, of which Yanick has written about and helped develop in Dancer. Regarding your App.pm setup: it's good practice to separate your routes according to entities (the way Catalyst requires you to do) and then load them. It doesn't have to be by entity, exactly the way Catalyst requires, but can also be by context. For example, I always set up MyApp/Admin.pm or MyApp/Routes/Admin.pm as all my administration routes. Then add a prefix '/admin'. It's that simple. On Wed, Mar 7, 2012 at 7:13 PM, Mr. Puneet Kishor <punk.kish@gmail.com>wrote:
On Mar 7, 2012, at 10:59 AM, sawyer x wrote:
Since it's all calls with subroutine references, you could implement this using loops and callbacks or closures.
I generally think it's a bad idea. Over-engineering.
It does seem like over-engineering, and does smell of being a bad idea. However, the alternative seems just as bad. Write all the routes in the Dancer app.pm. Then, write all the routes and their parameters as rules for a validation engine.
And, finally, record all the routes and their metadata (parameters, who/what/why/how) so users can get meta information about the app -- what all does this app do? Since this is a kinda data-warehousing effort (I am sure I am misusing the term data-warehousing), it is important to somehow provide this information to the users.
-- Puneet Kishor
Thank you for so patiently responding to my queries. I will provide more background, and since I going to respond to all your points, I will top post it here -- Every route I have points to an independent resource. Following the best of REST principles, every independent resource (unique noun) is identifiable by a unique URI. The actual result returned from the query can be throttled using query strings. All the resources don't belong in one namespace. They are indeed grouped in separate categories, and hence, they are in separate app1.pm, app2.pm, app3.pm, and so on. I use the `load_app 'geoplates', prefix => '/geoplates';` syntax to load each of those apps. You can actually try them out at http://earth-base.org/pbdb http://earth-base.org/geomaps http://earth-base.org/geoplates http://earth-base.org/macrostrat and so on. Actually, the above links lead to the web-browsable views, actually browser applications. Each one of them has sub-resources that can be reached via the command line (or the browser, if you prefer). For example http://earth-base.org/pbdb/collections.json?polygon=POLYGON((-111.26%2040.58...)) http://earth-base.org/geoplates/plates.json http://earth-base.org/macrostrat/cols/voronoi.json?polygon=POLYGON((-111.26%...)) and so on. What I want is for a user to be able to -- 1. query for *all* the available resources under a namespace (a prefix); 2. type any resource, and if it requires any params, get back a message providing the usage; 3. get back the correct usage if a wrong param is provided; and, even more ambitiously, allows new resource providers to register their own offerings so if a new resource called "foobar" has been properly registered, http://earth-base.org/foobar will know what do to... HTTP redirect to another site, or provide some cached information, or whatever. Hope that provides the background picture of what I am trying to accomplish. Dancer has been a fantastic platform to create all this. The above links are just a tip of the iceberg. There is nothing *micro* about Dancer when it comes to creating a very elegant solution to this complex project, and so far I have not been let down. On Mar 7, 2012, at 11:38 AM, sawyer x wrote:
I'm not sure what your application is or does, but it shouldn't have so many routes that you would need to refactor their creation using a factory. This isn't even done in Catalyst, and clearly should not be done in something that is supposed to be *micro* like Dancer.
I think what you have is, perhaps, an unwise setup of routes.
For example, you could set up more generic routes that catch more situations and differ between them using variables: instead of "get '/user/view/:id' => sub { ... }", you could set up "get '/user/:action/:id' => sub { ... }" or "get '/:entity/:action/:id' => sub { ... }".
Another very good way is to use chained routes, of which Yanick has written about and helped develop in Dancer.
Regarding your App.pm setup: it's good practice to separate your routes according to entities (the way Catalyst requires you to do) and then load them. It doesn't have to be by entity, exactly the way Catalyst requires, but can also be by context. For example, I always set up MyApp/Admin.pm or MyApp/Routes/Admin.pm as all my administration routes. Then add a prefix '/admin'. It's that simple.
On Wed, Mar 7, 2012 at 7:13 PM, Mr. Puneet Kishor <punk.kish@gmail.com>wrote:
On Mar 7, 2012, at 10:59 AM, sawyer x wrote:
Since it's all calls with subroutine references, you could implement this using loops and callbacks or closures.
I generally think it's a bad idea. Over-engineering.
It does seem like over-engineering, and does smell of being a bad idea. However, the alternative seems just as bad. Write all the routes in the Dancer app.pm. Then, write all the routes and their parameters as rules for a validation engine.
And, finally, record all the routes and their metadata (parameters, who/what/why/how) so users can get meta information about the app -- what all does this app do? Since this is a kinda data-warehousing effort (I am sure I am misusing the term data-warehousing), it is important to somehow provide this information to the users.
-- Puneet Kishor
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (3)
-
Mr. Puneet Kishor -
Puneet Kishor
-
sawyer x