--On 5. Januar 2007 21:22:24 +0100 Jens Vagelpohl [EMAIL PROTECTED]
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 12:57, Andreas Jung wrote:
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
I merged the
Jens Vagelpohl wrote:
On 6 Jan 2007, at 12:57, Andreas Jung wrote:
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
I merged the changes... hopefully
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 15:34, Hanno Schlichting wrote:
I had to change two things in CMF so far though. Here are the
patches I
came up with:
Thanks Hanno, this is a point I wanted to bring up after getting the
last work done: When using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 16:03, Martin Aspeli wrote:
I would say it's very bad if we need to train people on when aq-
wrapping tools (using __of__() say) is required and when it's not.
In fact, I'd say its catastrophic and will break incredible amounts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rocky Burt wrote:
On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote:
Hhm, I'm not sure what the best way is here. Personally I would like to
get rid of as much of Acquisition as possible, but obviously we need to
be careful here.
+10
Martin Aspeli wrote:
Jens Vagelpohl wrote:
My concern is just that we need a robust solution that doesn't put too
much onus on the end developer. If I have to do this it's pretty
horrendous:
mtool = getUtility(IMembershipTool)
mtool = mtool.__of__(context)
# now use mtool
Hanno Schlichting wrote:
Yep, you are wrong ;)
Fair enough. Out of curiosity, does the object have a __parent__?
In any case, I think your original suggestion is a good one. Let's take
this opportunity to diagnose the problem and not the symptom: True
tools should be singletons and act
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the acquisition intermingling. I'm not sure they'd
apply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 21:49, Martin Aspeli wrote:
Also, getToolByName remains and is almost certainly the way forward
for all TTW code still, because it lets us aq wrap, it removes the
need to make all interfaces importable in untrusted code, and it
Hanno Schlichting wrote:
The idea is to use a specialized persistent component registry, that
does the needed AQ-wrapping.
This will however only give us AQ-wrapped local utilities, whereas those
registered with the global component registry wouldn't be wrapped. I
think this might be an
Okay, spoke to Philipp on IRC and he asked me to relay his opinions on
some of this:
- CMF tools ought not to depend on acquiring things from 'self' if at
all possible.
- TTW code will need aq contexts for security. However, it makes sense
for getToolBy(Interface)Name() to handle this.
Hanno Schlichting wrote:
Martin Aspeli wrote:
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the
13 matches
Mail list logo
