[Dancer-users] automating the creation of routes

[Mr. 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,-111.62%2045.83,-102.83%2045.21,-111.26%2040.58))

	http://earth-base.org/geoplates/plates.json

	http://earth-base.org/macrostrat/cols/voronoi.json?polygon=POLYGON((-111.26%2040.58,-111.62%2045.83,-102.83%2045.21,-111.26%2040.58))

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 at 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 at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users