On Oct 24, 2015, at 11:48 AM, Sawyer X <[email protected]> wrote: > > On Sat, Oct 24, 2015 at 1:16 AM, Warren Young <[email protected]> wrote: >> On Oct 23, 2015, at 2:38 PM, Sawyer X <[email protected]> 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 > > I generally agree that you need to take care when growing on how to > extend. Rather than because we're "policy-free" (I like the term), we > just haven't realized that we should (and if this is your point, I > agree with you) make an effort to document how we recommend doing it, > rather than just making it possible.
I very much want Dancer to remain policy-free. Frameworks like Catalyst that make all of these decisions for you are easier to start with, but every time your design choice runs into one of the framework’s design choices, the framework usually wins, forcing you to change your app to conform. This is not to say that Catalyst and such are bad. They’re fine if your app fits their design. For Catalyst, that means MVC, which implies that the M, V, and C either are all in Perl, or can be sensibly wrapped in Perl code that Catalyst can call directly. My app is not like that. To the extent that there is a “model” at all in the app, it’s two or three layers away from the Perl code, and not really factored as an MVC-style Model anyway. Likewise, there really is no Controller in my app, and if I had to extract it as such, it would be composed mainly of JavaScript and C++ code, rather than being Perl code that interacted closely with Dancer, the Model, and the Views. There are plenty of Views in my Dancer app, but without a linked Model or Controller, there is no MVC going on. All of this makes an MVC framework either useless or an impediment for my sort of app. Dancer works much better for this sort of app, because it’s just a box of tools. It doesn’t tell me how to write my app. The downside is that I have to do some work that another framework might do for me. I’ll take that tradeoff happily. But to drag all of this back on the immediate topic, it is useful to see one way that those tools can be used. If someone else came up to you and wanted to write substantially the same sort of article, you should accept, because that developer will do it differently. And that’s a good thing! > I wrote an article about the "appname" feature which helps with that, You mean this one, I presume: http://advent.perldancer.org/2014/10 Yes, it’s a good point. My article should touch on these points again, without entirely repeating them. I must confess, I’m still using D1, so this issue has not affected me. > the "setup" method practice I have This one? http://advent.perldancer.org/2014/18 I think that’s orthogonal to what I want to cover. _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
