Malthe Borch mbo...@gmail.com writes:
I always found configuration overrides (e.g. ZCML's includeOverrides
directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a
configuration context like so:
adapter zcml:priority=100 ... /
On Sat, Dec 4, 2010 at 9:21 PM, Ross Patterson m...@rpatterson.net wrote:
Recently I had a conversation with someone or read something about using
add-on specific stacked component registries. Would this be the best
way to solve these kind of problems? Unfortunately I can't remember
where I
On Sat, Dec 04, 2010 at 12:21:02PM -0800, Ross Patterson wrote:
Malthe Borch mbo...@gmail.com writes:
I always found configuration overrides (e.g. ZCML's includeOverrides
directive) to be difficult to manage and hard to get right.
I'd like to echo Malthe's concern here. I've had many
On 02/12/2010 08:15, Malthe Borch wrote:
I always found configuration overrides (e.g. ZCML'sincludeOverrides
directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a
configuration context like so:
adapter zcml:priority=100 ...
On Thu, Dec 02, 2010 at 09:15:44AM +0100, Malthe Borch wrote:
I always found configuration overrides (e.g. ZCML's includeOverrides
directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a
configuration context like so:
On 3 December 2010 11:41, Chris Withers ch...@simplistix.co.uk wrote:
I'd much prefer it to just be an order of execution thing, the nyou have
total and flexible control. Combined with some logging about why something
is as it is and you have your solution.
It's not always possible to control
I always found configuration overrides (e.g. ZCML's includeOverrides
directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a
configuration context like so:
adapter zcml:priority=100 ... /
Default priority would be 0, traditional
On Thu, Dec 2, 2010 at 3:15 AM, Malthe Borch mbo...@gmail.com wrote:
I always found configuration overrides (e.g. ZCML's includeOverrides
directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a
configuration context like so:
On 2 December 2010 13:34, Benji York be...@benjiyork.com wrote:
I appreciate the flexibility inherent in that approach, but personally,
I'd be frightened of such a system. I sometimes have problems figuring
out which directives are active in the current system, if I had to
reason about dozens
On Thursday, December 02, 2010, Malthe Borch wrote:
As far as I understand, for a ZCML include override to work properly,
you need to carefully make sure that your includes are in the exact
right order and on the same level. In a system where two packages are
trying to override the same
On 2 December 2010 14:37, Stephan Richter srich...@cosmos.phy.tufts.edu wrote:
This explanation helped me to understand where you come from. I think I would
be okay with the priority feature, but could we maybe limit it to the
configure element? Since you can use this element anywhere and it
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch mbo...@gmail.com:
As far as I understand, for a ZCML include override to work properly,
you need to carefully make sure that your includes are in the exact
right order and on the same level. In a system where two packages are
trying to override
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2010 03:43 PM, Charlie Clark wrote:
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch mbo...@gmail.com:
As far as I understand, for a ZCML include override to work properly,
you need to carefully make sure that your includes are in the
13 matches
Mail list logo
