[dancer-users] Dancer Advent Calendar 2015

[Warren Young]

On Oct 23, 2015, at 2:38 PM, Sawyer X <xsawyerx at gmail.com> wrote:
> 
> email back to the list (or to me) your suggestions.

The generated dancer -a code and the examples mostly show simple cases which are fine starting points, but they don’t tell you how to scale the app if it starts getting large.  General Perl-in-the-large principles help, but there are aspects of how that interacts with Dancer that aren’t obvious.

If you start with the generated code and extend it in the most straightforward manner, you end up with all your code in lib/App.pm, with a flat route definition set.  This is bad, and it is the problem I want to address.

When you write a program with thousands of lines and a deep URL hierarchy, you start to want to break it up, but the current docs don’t really tell you how to do that sensibly.  Dancer is not a policy-free framework, which means that it not only doesn’t force you to do it the right way, it doesn’t even give hints about what the right way might be.

It may be too much for a single article, but I would like to cover topics such as:

1. Nested route definitions:

        # User management pages
        prefix ‘/user’ => sub {
            get  ‘/login’ => …
            post ‘/logout’ => …
        };
         
        # Major user-visible web app feature for logged-in users
        prefix ‘/feature’ => sub {
            prefix ‘/record’ => sub {
                # Define RESTful CRUD API for /feature/record objects
                del  ‘/:id’ => …
                get  ‘/:id’ => …
                post ‘/’ => …
                put  ‘/’ => …
            };
        };

        # An API for use by the site’s JS code and possibly third parties
        prefix ‘/api’ => sub {
            prefix ‘/something’ => …
        };

Not only does defining your URL hierarchy this way instead of in the flat way that is most obvious avoid a lot of redundancy (‘/feature/record/:id’), defining things this way often makes patterns jump out at you, allowing an improvement in the way you design your URL scheme.

2. Moving almost all code out of the generated lib/App.pm into other *.pm files in that directory, possibly nested into a directory hierarchy. (lib/App/Module.pm, etc.)  Naming schemes, how to call between modules, etc.

3. Given 1 and 2, how to shard the route definitions among lib/App/*.pm, so that each Perl module includes only the routes that it defines code to handle, rather than dumping the whole route definition into the main lib/App.pm file generated by dancer -a.

4. Given 1 and 2, how to name the content of the views directory.  (e.g. views/app/feature.tx or views/app/feature/page-fragment.tx)  Policy-heavy frameworks use the calling URL to work out where the template files are, but Dancer doesn’t enforce that.  Working out a good naming scheme is essential for maintainability.

5. Your ideas here!