Re: [Repoze-dev] imperative configuration prevents application extension?
Chris Rossi wrote: FWIW, I can imagine something spelled sort of like: @bfg_view(name='something', overrides='baseapp.views.someview') def my_view(request): +lots Yeah, I hadn't replied 'cos I couldn't think of how to spell what I was after. This is spot on, and would, in theory, allow an app to override a library that overrides a framework. cool :-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Thu, May 6, 2010 at 4:14 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) I hate to just make more work for Chris M. I'm happy to add this to my todo list. I have a lot on my plate right now, so don't expect a timely implementation, but I'll try to get to it . . . . sometime. Chris R ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote: On Thu, May 6, 2010 at 4:14 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) I hate to just make more work for Chris M. I'm happy to add this to my todo list. I have a lot on my plate right now, so don't expect a timely implementation, but I'll try to get to it . . . . sometime. I'm actually not 100% confident that I understand the syntax, so I don't think I could implement it yet anyway. With ovverides='some.funcion.or.method', is the function or method being overridden assumed to have a view configuration attached to it that matches the overriding view configuration? If so, that's a little weird. What if it has different view configuration arguments or or no view configuration arguments at all? A good number of view configuration overrides as performed via ZCML don't require creatign separate view callable (like changing the rendererer), so constructing one just to be able to decorate it, then delegating to the original, seems a little suspect. I'm also not sure that this can be advertised as an overrides strategy 100% comparable to ZCML unless all the various ZCML directives get Python declarative equivalents. So.. yeah, I think there's a cool idea lurking in here, but I'm not sure we found it yet. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Thu, May 6, 2010 at 10:49 AM, Chris McDonough chr...@plope.com wrote: On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote: On Thu, May 6, 2010 at 4:14 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) I hate to just make more work for Chris M. I'm happy to add this to my todo list. I have a lot on my plate right now, so don't expect a timely implementation, but I'll try to get to it . . . . sometime. I'm actually not 100% confident that I understand the syntax, so I don't think I could implement it yet anyway. With ovverides='some.funcion.or.method', is the function or method being overridden assumed to have a view configuration attached to it that matches the overriding view configuration? If so, that's a little weird. What if it has different view configuration arguments or or no view configuration arguments at all? A good number of view configuration overrides as performed via ZCML don't require creatign separate view callable (like changing the rendererer), so constructing one just to be able to decorate it, then delegating to the original, seems a little suspect. I'm also not sure that this can be advertised as an overrides strategy 100% comparable to ZCML unless all the various ZCML directives get Python declarative equivalents. So.. yeah, I think there's a cool idea lurking in here, but I'm not sure we found it yet. Good point. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On 05/06/2010 08:49 AM, Chris McDonough wrote: I'm also not sure that this can be advertised as an overrides strategy 100% comparable to ZCML unless all the various ZCML directives get Python declarative equivalents. So.. yeah, I think there's a cool idea lurking in here, but I'm not sure we found it yet. IMHO, the ZCML support for overrides is sufficient already. If I need to override anything in my app, I expect to write at least 2 ZCML files. configure.zcml: configure scan module=.views / includeOverrides file=overrides.zcml / /configure overrides.zcml: configure scan module=.overrides / /configure I will put most of my views in views.py. When ZCML detects a conflict, I'll move the conflicting view declarations to overrides.py. This doesn't currently work because bfg_view decorators cause imperative configuration. If bfg_view decorators caused declarative configuration instead, I expect that ZCML overrides would just work, as would automatic conflict detection. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On Wed, May 5, 2010 at 1:34 PM, Chris McDonough chr...@plope.com wrote: On Wed, 2010-05-05 at 19:19 +0200, Charlie Clark wrote: Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough chr...@plope.com: 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. Would it make sense to raise a configuration error like ZCML does? Probably. This would be most consistent. Decorator configuration is more like ZCML than it is like imperative configuration. +1 FWIW, I can imagine something spelled sort of like: @bfg_view(name='something', overrides='baseapp.views.someview') def my_view(request): ... If the overriding registration specifically calls out what it is its overriding you can still figure out who's supposed to win in a conflict without trying to rely on scan order. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
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 ? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On 04/28/2010 03:07 PM, Chris Withers wrote: Hi All, In the BFG book their are copious references to the fact that using imperative configuration (or the decorators, my preferred choice) is bad if you plan to write apps that might be extended by others. Am I right in understanding that this is because that method of configuration somehow prevents overrides being applied later? No. You can always override an individual registration (obtained via imperative configuration, a scan, or via ZCML) with a subsequent imperative registration. You can even call load_zcml twice with two different files; the second time it runs it will override the registrations done during the first run. But usually you can't unregister something; there's no API for unregistration of views, for example. But at the end of the day, it kinda doesn't matter. The framework just provides mechanism; it's really the application developer's responsibility to chunk things appropriately so they can be reused, extended, or omitted. A poor developer can make that hard even if he uses ZCML as a registration mechanism: he might put all of the registrations in a single ZCML file so that someone who wants to take only some of the registrations must effectively take all of them or none of them. In the meantime, another developer might succeed when he tells folks reuse his decorator-configured application by documenting how to add individual registrations imperatively. In my mind, using ZCML for frameworky apps that you distribute widely (to people you don't know and may never know) has one advantage: it's slightly easier to recover from poorly chunked registrations when they're all done via ZCML. This is because the very worst case scenario is that the integrator doesn't bother trying to reuse *any* ZCML from the package he's trying to reuse and he just duplicates all of the registrations in a separate set of ZCML files somewhere else in the integration. Obviously something similar could also be done with decorators (just comment out the scan and either do imperative config or ZCML in its place). But with ZCML you can usually just cut, paste, and change. If ZCML was not in the picture, you're often probably going to need to think about converting decorator based registrations into imperative analogues or ZCML instead of cut-paste-change. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
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? What happens if a scan finds two decorators for the same thing? But at the end of the day, it kinda doesn't matter. The framework just provides mechanism; it's really the application developer's responsibility to chunk things appropriately so they can be reused, extended, or omitted. So why the big warnings in the book? A poor developer can make that hard even if he uses ZCML as a registration mechanism: he might put all of the registrations in a single ZCML file so that someone who wants to take only some of the registrations must effectively take all of them or none of them. Isn't that what people generally do with zcml and why zcml's overrides ability exists? Obviously something similar could also be done with decorators (just comment out the scan and either do imperative config or ZCML in its place). But with ZCML you can usually just cut, paste, and change. If ZCML was not in the picture, you're often probably going to need to think about converting decorator based registrations into imperative analogues or ZCML instead of cut-paste-change. It's something that's always bugged me and neither zcml nor anything else I've seen allow; the idea of turning off an existing piece of configuration. Decorators are a little harder 'cos you can't safely rely on the last one wins philosophy so you end up needing some kind of ordering, or raising an exception if something is defined more than once, which precludes one package customising stuff from another if they both use decorators - which is what I'm ideally aiming for :-/ What ideas do people have in these areas? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
Am 29.04.2010, 13:32 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: So why the big warnings in the book? They're not warnings but reasoned guidance and developer preference. External configuration à la ZCML was not invented by Zope. XML is verbose but good editor support makes things a lot easier. A poor developer can make that hard even if he uses ZCML as a registration mechanism: he might put all of the registrations in a single ZCML file so that someone who wants to take only some of the registrations must effectively take all of them or none of them. Isn't that what people generally do with zcml and why zcml's overrides ability exists? Obviously something similar could also be done with decorators (just comment out the scan and either do imperative config or ZCML in its place). But with ZCML you can usually just cut, paste, and change. If ZCML was not in the picture, you're often probably going to need to think about converting decorator based registrations into imperative analogues or ZCML instead of cut-paste-change. It's something that's always bugged me and neither zcml nor anything else I've seen allow; the idea of turning off an existing piece of configuration. Disabling configuration rather than removing seems to me an invitation for trouble. But you could probably add a disable directive. Can you provide a real world example? Decorators are a little harder 'cos you can't safely rely on the last one wins philosophy so you end up needing some kind of ordering, or raising an exception if something is defined more than once, which precludes one package customising stuff from another if they both use decorators - which is what I'm ideally aiming for :-/ Which is one of the reasons why declarative configuration has its place. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
Charlie Clark wrote: Decorators are a little harder 'cos you can't safely rely on the last one wins philosophy so you end up needing some kind of ordering, or raising an exception if something is defined more than once, which precludes one package customising stuff from another if they both use decorators - which is what I'm ideally aiming for :-/ Which is one of the reasons why declarative configuration has its place. decorators *are* declarative configuration... Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
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. What happens if a scan finds two decorators for the same thing? Each adds some configuration. Neither cancels each other out. But at the end of the day, it kinda doesn't matter. The framework just provides mechanism; it's really the application developer's responsibility to chunk things appropriately so they can be reused, extended, or omitted. So why the big warnings in the book? For the reason I said at the end of my last email. When you distribute an application that uses ZCML for its configuration, it is possible to recover from bad chunking pretty easily. A poor developer can make that hard even if he uses ZCML as a registration mechanism: he might put all of the registrations in a single ZCML file so that someone who wants to take only some of the registrations must effectively take all of them or none of them. Isn't that what people generally do with zcml and why zcml's overrides ability exists? I dont know what other people generally do with ZCML. I personally try to break it up into one logical set of registrations per file. You still can't unregister something via overrides. Obviously something similar could also be done with decorators (just comment out the scan and either do imperative config or ZCML in its place). But with ZCML you can usually just cut, paste, and change. If ZCML was not in the picture, you're often probably going to need to think about converting decorator based registrations into imperative analogues or ZCML instead of cut-paste-change. It's something that's always bugged me and neither zcml nor anything else I've seen allow; the idea of turning off an existing piece of configuration. Zope has some add-on that lets you do this. I don't remember what it's called. Decorators are a little harder 'cos you can't safely rely on the last one wins philosophy so you end up needing some kind of ordering, or raising an exception if something is defined more than once, which precludes one package customising stuff from another if they both use decorators - which is what I'm ideally aiming for :-/ Yeah, that doesn't really work. Which is why we have the other modes. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] imperative configuration prevents application extension?
Hi All, In the BFG book their are copious references to the fact that using imperative configuration (or the decorators, my preferred choice) is bad if you plan to write apps that might be extended by others. Am I right in understanding that this is because that method of configuration somehow prevents overrides being applied later? If so, what can we do to change that? I've grown quite allergic to ZCML in the few years since I last had to touch it... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
On 04/28/2010 01:07 PM, Chris Withers wrote: In the BFG book their are copious references to the fact that using imperative configuration (or the decorators, my preferred choice) is bad if you plan to write apps that might be extended by others. Am I right in understanding that this is because that method of configuration somehow prevents overrides being applied later? If so, what can we do to change that? I've grown quite allergic to ZCML in the few years since I last had to touch it... I imagine Venusian makes it possible to treat decorators as declarative configuration, which is IMHO the right thing to do. :-) Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
