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
On Thu, May 6, 2010 at 10:49 AM, Chris McDonough wrote:
> On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote:
>> On Thu, May 6, 2010 at 4:14 AM, Charlie Clark
>> wrote:
>> > Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers :
>> >
>> >> This is spot on, and would, in theory, allow an app to overr
On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote:
> On Thu, May 6, 2010 at 4:14 AM, Charlie Clark
> wrote:
> > Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers :
> >
> >> This is spot on, and would, in theory, allow an app to override a
> >> library that overrides a framework.
> >
> > Cue lots
On Thu, May 6, 2010 at 4:14 AM, Charlie Clark
wrote:
> Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers :
>
>> 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
> cod
Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers :
> 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 Cons
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
On 5 May 2010, at 18:48, Chris Rossi wrote:
> On Wed, May 5, 2010 at 1:34 PM, Chris McDonough
> wrote:
>> On Wed, 2010-05-05 at 19:19 +0200, Charlie Clark wrote:
>>> Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough
>>> :
>>>
Relying on scan ordering is like relying on import ordering to
On Wed, May 5, 2010 at 1:34 PM, Chris McDonough wrote:
> On Wed, 2010-05-05 at 19:19 +0200, Charlie Clark wrote:
>> Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough :
>>
>> > Relying on scan ordering is like relying on import ordering to do
>> > configuration in an application. You can do it if
On Wed, 2010-05-05 at 19:19 +0200, Charlie Clark wrote:
> Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough :
>
> > 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.
Am 05.05.2010, 02:18 Uhr, schrieb Chris McDonough :
> 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 doe
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 subseq
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 over
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 d
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 t
Am 29.04.2010, 13:32 Uhr, schrieb Chris Withers :
> 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
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 decor
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 t
On Wed, Apr 28, 2010 at 3: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 under
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
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 someh
20 matches
Mail list logo
