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