Hello, 2013/1/3 Damien Krotkine <[email protected]>
> > We should accept that developers have the right to separate features by > packages, and not oblige them to group routes and hooks per package. > > Indeed, and I'd go even a step further: > Celogeek mentioned that this can be worked around by using roles but not > everybody ate fluent with them. > > So, I propose that one could specify the scope of a hook. > > By default a hook would be package-scoped. But we should make it possible > to scope it to the whole application ( if that's possible), and also be > able to scope it to a selection of routes, as David Golden mentioned. > > Maybe it's not the right solution, but at least you'll agree that there is > an issue in the current state ( I think English speaking people say "red > herring" :) > > You're absolutely right Damien, thanks to users like Celogeek who spend some time migrating a real application for 1 to 2, we've realized that the scoping we have in 2 is great, but is not _always_ what the user wants. I also think the "package scoping by default" is a good idea but it's clear now that we need a way to disable that in some places. I don't think it should be an exception for hooks, or even a kind of hooks. I think the user should be able to say : these apps (packages) share the same registry, or in other words, these are supposed to be merged into 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't share hooks or engines. We need a way to tell Dancer to load multiple apps as one, I'm not sure exactly how the DSL should be extended to allow 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 loading everything that is defined in the packages _into_ the current package. That would be, I think, the most generic and proper way to share settings, hooks and everything between "apps".
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
