On Tue, 2010-05-04 at 14:45 +0100, Chris Withers wrote:
> Chris McDonough wrote:
> > On 04/29/2010 07:32 AM, Chris Withers wrote:
> >> Chris McDonough wrote:
> >>> No. You can always override an individual registration (obtained via
> >>> imperative configuration, a scan, or via ZCML) with a subsequent
> >>> imperative registration.
> >>
> >> Okay, but how would I override a decorator with another decorator?
> > 
> > You won't.
> 
> Hmmm, that sure would be nice though ;-)
> 
> >> What happens if a scan finds two decorators for the same thing?
> > 
> > Each adds some configuration.  Neither cancels each other out.
> 
> I don't follow.
> 
> @bfg_view(name='something')
> def my_view1(request):
>      ...
> 
> @bfg_view(name='something')
> def my_view2(request):
>      ...
> 
> Which function gets called when I go to:
> 
> http://whatever/something

I thought you meant:

@bfg_view(name='one')
@bfg_view(name='two')
def my_view(request):
    ....

But you didn't.

In your example above, the last decorator to be found during a scan
wins, so the view configuration attached to view2 will be found.
Currently I think this is in module definition order.  But scan order is
not guaranteed; it's not a supported feature that one will override the
other forever.

Relying on scan ordering is like relying on import ordering to do
configuration in an application.  You can do it if you want, but you get
to keep both pieces when it breaks.

-C

_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to