Jim Fulton wrote:
I'd have no problem with generating actions in Python. It would allow
greater control and would probably make action generation much faster.
If we did this, We'd probably want to improve the action-generation
API. We'd also need to think about how action info should be
generat
Martijn Faassen wrote:
Jim Fulton wrote:
...
Anyway, I've seen lots of
testing code that does not avoid this. The people who wrote this test
might have done it unnecessarily, but that points to doing it the right
way apparently being harder than doing it the wrong way. Are you saying
this
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Yes, that's what I was thinkin
On Friday 17 March 2006 10:46, Jim Fulton wrote:
> I'll note, however, that I think there will be lots of interesting
> small Python applications that don't use zope.configuration.
> zope.configuration is helpful for providing flexible configuration
> of an application server. I think and hope that
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Yes, that's what I was thinking of too. Good. :)
Jim Fulton wrote:
Stephan Richter wrote:
On Friday 17 March 2006 06:34, Jim Fulton wrote:
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Of course, the undo feature has other benefits, suc
Stephan Richter wrote:
On Friday 17 March 2006 06:34, Jim Fulton wrote:
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Of course, the undo feature has other benefits, such as reloading
functi
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Yes, that's what I was thinking of too. Good. :)
[snip]
I was talking to Phil
On Friday 17 March 2006 06:34, Jim Fulton wrote:
> The idea is that after applying configuration, you'd keep the
> resolved sequence of actions around so that you could call their undo
> methods later.
Of course, the undo feature has other benefits, such as reloading
functionality without restart
Martijn Faassen wrote:
Jim Fulton wrote:
...
(Note that a flaw in this model is that we have no good way to undo
actions. We don't need this for normal execution, but it would be very
helpful for testing.)
Presumably you have thought about the registration of an equal and
opposite action wh
Jim Fulton wrote:
[snip very clear explanation of how zope.configuration works]
Thanks for putting this all in one place! The bit on conflict resolution
was helpful to my understanding - I hadn't seen it explained so clearly
before.
(Note that a flaw in this model is that we have no good way
Lets step back and look at why we created ZCML. A primary goal of the
component architecture was to make it easier to reuse packages. A
major problem with Zope 2 products is that they are hard to
customize. The CMF made this a bit better with skins. You could
override selected scripts or templat
Today it's very hard to debug ImportErrors raise inside modules
referenced through a zcml directive, because the ImportError is
swallowed an no traceback comes back to the user. Just a
ConfigurationError: ('Invalid value for', 'class', "Couldn't
import some.class, cannot import name somenam
13 matches
Mail list logo
