How do you minimise code in Main.pm? (looking for good Dancer2 patterns)
Hi all, I get the sense that we are using Main.pm very poorly and a bit of Dancer2 architectural insight would greatly improve the quality of our code. What is the best pattern for the breakdown between perl module/Dancer2 route handler/TT file? For example, if you have a sub-system for administrators that manages the fees tables and reports, would you put these into separate route handlers? eg. ReportsHandler.pm => Route handler for reports - Instantiates an instance of Reports.pm in it's "before" hook so we only need to do this once (or in the module itself?) - the 'view' and 'save' routes call the appropriate 'get' and 'set' methods for that table in Reports.pm and a separate handler for Fees, with an overarching Main.pm route handler that largely deals with mainstream userspace routes (any significant user workflows get their own router handler module like ReportsHandler and FeesHandler)? Ideally, I'd like all our code in the perl modules, with the route handler doing nothing but dispatch (with error handling) and the TT doing basic interface presentation. But at the moment, each route handler is 20-30 lines long - I think they should be ~5 lines long or less. An exemplar Main.pm + TT file would be very helpful! cheers, Nathan
On Aug 21, 2017, at 9:52 PM, Nathan Bailey <web@polynate.net> wrote:
I get the sense that we are using Main.pm very poorly and a bit of Dancer2 architectural insight would greatly improve the quality of our code.
You might benefit by reading through my “Medium-Scale Dancer” article series from this past year’s Perl Dancer Advent calendar, then: http://advent.perldancer.org/2016/3 http://advent.perldancer.org/2016/4 http://advent.perldancer.org/2016/5 http://advent.perldancer.org/2016/6 http://advent.perldancer.org/2016/7
What is the best pattern for the breakdown between perl module/Dancer2 route handler/TT file?
That’s covered in part 2 of the series linked above.
For example, if you have a sub-system for administrators that manages the fees tables and reports, would you put these into separate route handlers? eg. ReportsHandler.pm => Route handler for reports - Instantiates an instance of Reports.pm in it's "before" hook so we only need to do this once (or in the module itself?)
I think you’re getting a long way away from Dancer here. I suspect you’re trying to architect your entire application in terms of Dancer, whereas Dancer proper is likely only one element in your application’s overall functionality. That is to say, you have an application that *happens* to present its user interface via a dynamic web site, but there are many elements of the application that are not a web app per se. You should be building the application in layers. Everything you speak of in the above quote seems to belong at least one layer down beyond the UI elements you deliver via Dancer. Those layers and interfaces may be mirrored to some extent in the route definitions, but don’t feel bound to do that mirroring, much less to couple business logic to route handlers. Given the cost of HTTP round-trips, there is great incentive for the route definitions to map one-to-many to internal API calls. The old CGI/PHP/ASP model is an extreme example of this: make a single HTTP request and get back a completed UI, then submit some information and get back another whole UI. Dancer doesn’t change the fundamental limitations imposed by network round-trip times.
But at the moment, each route handler is 20-30 lines long - I think they should be ~5 lines long or less.
The article series covers that as well: most of my route handlers are *one* line long.
participants (2)
-
Nathan Bailey -
Warren Young