[Dancer-users] automating the creation of routes

sawyer x xsawyerx at gmail.com
Wed Mar 7 18:38:16 CET 2012


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20120307/095ee547/attachment.htm>


More information about the Dancer-users mailing list