Though doing it this way requires the user to maintain a manifest or some sort of class loading system, does it not?
Cheers,
Rik
Sorry, top posting...An other way is to think about it bottom up instead of top downInstead of the parent app including the children packages, we could do :package App::Foo;use Dancer scope => qw(App);It's a bit like in relational database where you say who your parent is, not who your children are.It Also avoids to change the parent package every time you add a child.Also it makes it possible to use dancer with more than one scope. Not why it would useful though :)We should probably look at breadboard and catalyst, see how they do it. David, I think you have experience with catalyst?And that brings up the fact that we should use a serious tool to handle dancer 'use' options. Can we try an enhanced sub::exporter or similar?Le vendredi 4 janvier 2013 à 13:57, David Precious a écrit :
On Fri, 4 Jan 2013 10:28:43 +0100Alexis Sukrieh <sukria@sukria.net> wrote:I think the user should be able to say : these apps (packages) sharethe same registry, or in other words, these are supposed to be mergedinto one app.For instance:package App;use Dancer;use App::Foo;use App::Bar;In this example, everything in Foo and Bar are in a jail, they don'tshare hooks or engines. We need a way to tell Dancer to load multipleapps as one, I'm not sure exactly how the DSL should be extended toallow that, but here is the idea I have in mind:package App;use Dancer;consume 'App::Foo', 'App::Bar';That new "consume" keyword would be responsible for loadingeverything that is defined in the packages _into_ the currentpackage. That would be, I think, the most generic and proper way toshare settings, hooks and everything between "apps".Hmm, I like that; the sounds like it could be a good solution to theproblem.I definitely think it should be possible to load routes etc fromdifferent packages but have them share a scope for config / hooks etc.At $work, we have a very large Dancer app, with routes defined invarious packages (grouped logically); however, we have before hookswhich should run for all routes, and session engine / serializer etcsettings which apply to all; we'd need to be able to do the same with D2one way or another.Part of me wonders if the auto scope-per-package stuff should beconfigurable, so you could request D1-style "all in one" behaviour ifdesired, but I'm not sure.--David Precious ("bigpresh") <davidp@preshweb.co.uk>_______________________________________________dancer-users mailing list
_______________________________________________
dancer-users mailing list
dancer-users@dancer.pm
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users