[dancer-users] Re : Re : Re : Before Hook hit multiple times.

Damien Krotkine dkrotkine at gmail.com
Fri Jan 4 14:59:20 GMT 2013



Le vendredi 4 janvier 2013 à 14:26, Rik Brown a écrit :

> Though doing it this way requires the user to maintain a manifest or some sort of class loading system, does it not?
>  
>  


I need to check the code, but if I'm correct, the app object is stores as a package variable ( well, subroutine ).

 Maybe we can keep an app object per package, but it can be the same object shared across multiple package.  
  
So you would say :

package Child;
use My::Parent;
use Dancer scope => 'My::Parent';

That would Do exactly as usual ( install the app object in Child, but instead of creating a new app object, get it from My::Parent. Or have *Child::dsl = \&My::Parent::dsl.  

Also, use Dancer scope => 'My::Parent'; could use My::Parent behind the scene.  

Alexis, what do you say ?

> Cheers,
> Rik  
> On 4 Jan 2013 13:21, "Damien Krotkine" <dkrotkine at gmail.com (mailto:dkrotkine at gmail.com)> wrote:
> > Sorry, top posting...  
> >  
> > An other way is to think about it bottom up instead of top down
> >  
> > Instead 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 +0100
> > > Alexis Sukrieh <sukria at sukria.net (mailto:sukria at sukria.net)> wrote:
> > > > 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".
> > > >  
> > >  
> > >  
> > > Hmm, I like that; the sounds like it could be a good solution to the
> > > problem.
> > >  
> > > I definitely think it should be possible to load routes etc from  
> > > different packages but have them share a scope for config / hooks etc.
> > >  
> > > At $work, we have a very large Dancer app, with routes defined in
> > > various packages (grouped logically); however, we have before hooks
> > > which should run for all routes, and session engine / serializer etc
> > > settings which apply to all; we'd need to be able to do the same with D2
> > > one way or another.
> > >  
> > > Part of me wonders if the auto scope-per-package stuff should be  
> > > configurable, so you could request D1-style "all in one" behaviour if
> > > desired, but I'm not sure.
> > >  
> > >  
> > > --  
> > > David Precious ("bigpresh") <davidp at preshweb.co.uk (mailto:davidp at preshweb.co.uk)>
> > > http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter (http://www.preshweb.co.uk/twitter)
> > > www.preshweb.co.uk/linkedin (http://www.preshweb.co.uk/linkedin) www.preshweb.co.uk/facebook (http://www.preshweb.co.uk/facebook)
> > > www.preshweb.co.uk/cpan (http://www.preshweb.co.uk/cpan) www.preshweb.co.uk/github (http://www.preshweb.co.uk/github)
> > >  
> > >  
> > > _______________________________________________
> > > dancer-users mailing list
> > > dancer-users at dancer.pm (mailto:dancer-users at dancer.pm)
> > > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > _______________________________________________
> > dancer-users mailing list
> > dancer-users at dancer.pm (mailto:dancer-users at dancer.pm)
> > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
> >  
> _______________________________________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20130104/6c553a7f/attachment.htm>


More information about the dancer-users mailing list