Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL
traversal code would move to zope.tales. zope.container would depend
on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for
zope.container to
Jim Fulton wrote:
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL
traversal code would move to zope.tales. zope.container would depend
on zope.tales rather than on zope.traversing.
For my own
Tres Seaver wrote:
Hanno Schlichting wrote:
Log message for revision 101616: Revert r101557 and put back
version pins for zodbcode and zope.app.interface. These are actual
dependencies of zope.app.zcmlfiles, which in turn is a test
dependency of numerous packages we use. Having a consistent
Hanno Schlichting wrote:
I kind of suspect that we are seeing the results of
http://www.python.org/dev/peps/pep-0353 though.
That is very likely. BTW, that PEP links to a handy tool that reveals
most 64 bit portability issues in Python-oriented C code.
From what I understand we need to
Marius Gedminas wrote:
On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote:
Hi,
the doctests for zope.index 3.5.2 - as used in Zope 2.12 - fail badly:
File
/home/ajung/.buildout/eggs/zope.index-3.5.2-py2.6-linux-x86_64.egg/zope/index/text/tests/../textindex.txt,
line 143, in
Chris McDonough wrote:
On 8/3/09 1:07 PM, Shane Hathaway wrote:
How insane were these tests? Well, the author of the tests noticed that
the C optimization produces different scores than the Python version,
and compensated for that in a way that dramatically reduced readability.
/me hangs
Fabio Tranchitella wrote:
Is there a specific reason for having the version pinning? Automatic testing
of
zope.tales obviously fails using the KGS, because zope.traversing there is
3.7.1.
Is it possible to remove the versions stanza?
Sure. Pinned versions are OK for a maintenance branch,
Fabio Tranchitella wrote:
My knowledge of the zope.publisher is too limited to do any change in this
area, but to me it looks like these configurations (both of them) should be
perfomed by zope.app.publisher (removing the dependency zope.container -
zope.publisher), but conditionally
Hi Dan,
I'll provide feedback for a few parts of your proposal.
Dan Korostelev wrote:
xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out. ;-)
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to clearly
distinguish WebDAV requests, then I imagine this
Hermann Himmelbauer wrote:
Hi,
I once in the while get the following warning in my Zope 3 log, which I'd
like
to resolve:
2009-10-07T14:35:41 WARNING ZopePublication Competing writes/reads
at
/BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/c/acc/booklist/index.html:
database
Hermann Himmelbauer wrote:
That's exactly the problem - it's a read operation and there should not be
any
write operation involved. However, it's hard to find out where the write
operation in my code occurs, I can't find it in the view, maybe there's
something in the authentication code,
Martijn Faassen wrote:
But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan
Martijn Faassen wrote:
Given some feedback about backwards compatibility, I'm leaning to the
following adjusted scenario:
* allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation.
It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is*
actually symmetric
Lennart Regebro wrote:
On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote:
If adding lookup() is a good idea
Possibly, but it sound like you are looking up (a), when in fact you
are adapting it. :) Maye IFoo.adapt(a) ?
+1, IFoo.adapt() is better, along
Gary Poster wrote:
Then to the multiadapter concern I raised, all my real-world examples
of adapters are to adapt one object so it can be used in a certain
way (to integrate with another kind of object). Power adapters, for
instance, adapt a plug (required interface) so it can plugged in to
Martin Aspeli wrote:
Gary Poster wrote:
I think I could get fully behind the following proposal that others have
made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Thinking about it a bit, it strikes me that IFoo.adapt(context) may not
be right. This reads
Wolfgang Schnerring wrote:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
Godefroid Chapelle wrote:
I tried to follow this discussion closely: however, I cannot say that I
understand if doing multi-adaptation with IFoo(bar, baz, boo) has been
rejected or postponed.
AFAICT, the decision to reject or postpone that has been postponed. :-)
Shane
Martin Aspeli wrote:
Can we all get back to our lives now? :-)
FWIW, I try to participate in discussions like these by reading and
writing only short emails. I find that I don't miss much that way.
Life is more enjoyable without essay-mails.
Shane
Hanno Schlichting wrote:
It has a dependency on zope.app.publication. Given the central role of
zope.traversing I allowed it and zope.app.publication to stay in the
ZTK, but moved it to the under-review option.
On the zope.traversing trunk, I have removed the zope.app.publication
dependency.
Lennart Regebro wrote:
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's
only me. :)
I agree that the debate is confused. No one intends to
Jan Ulrich Hasecke wrote:
On 04.01.10 19:23, Baiju M wrote:
Hi All,
I am proposing to call Zope 3 - the web frame work
as BlueBream. The main use for name is documentation.
Coming from marketing I strongly suggest to think twice or better thrice
before inventing the next new name
Christian Theune wrote:
This is a mailinglist and you probably have dumped your address book to
the invitation system. I've seen a couple of those talk to Zope
mailinglists recently. Can you *please* avoid putting mailing list
addresses into those systems?
Better yet, I wonder if there is
On 07/02/2010 11:49 AM, Tres Seaver wrote:
Jim has asserted (but not really explained) that the C extension closes
some kind of security hole. I don't see any credible attack vector
myself, but then I no longer believe it worthwhile to devote my own
energy to defending against malicious TTW
On 12/07/2010 12:27 PM, Chris McDonough wrote:
I *think* I'm of the opinion that libraries (or even reusable
applications) probably shouldn't need to use includeOverrides.
+1, I would be very suspicious of any library that uses
includeOverrides. Any use of it ought to be highly visible to
On 03/21/2011 10:59 AM, Chris McDonough wrote:
On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote:
It's easy and clear, but has the drawback of encouraging that
registration is done on import time, while scanning separates the
registration from the definition. I'm not sure how important
On 04/04/2011 10:22 AM, Roger wrote:
Just because you can write login forms with
z3c.form this package has nothing to do with
authentication. That's just a form framework!
Authentication is defently not a part
of our z3c.form framework and should not
become one.
Why do you think
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
The ZMI is a highly insecure, completely outdated and user-unfriendly
interface.
As I read this, I got an idea for a possible way forward. I haven't
been reading zope-dev much lately, so forgive me if something like this
has been mentioned
On 04/12/2013 11:59 AM, Chris Withers wrote:
On 14/03/2013 08:01, Marius Gedminas wrote:
What's the official location of RelStorage? I see two source trees:
* http://zope3.pov.lt/trac/browser/relstorage/trunk
* https://github.com/zodb/relstorage
They have the same commits (~1 year
Lennart Regebro wrote:
On Sat, Jan 31, 2009 at 20:23, Simon Michael si...@joyful.com wrote:
Oh. That seems a pity, with Zope 3.4 just out; a site facelift would
help. Would the designer care to comment ?
Finding a new designer shouldn't be that tricky. I know somebody that
can skin a Plone
JeanMichel FRANCOIS wrote:
I have tested RelStorage with Zope3.4 and i m happy with it. I would
like to know if it's usable with Zope 2.9. I'm not sure, but Zope2.9 is
release with a ZODB==3.6 and RelStorage need ZODB==3.7, isn't it ?
I think RelStorage could work with ZODB 3.6, but the
601 - 632 of 632 matches
Mail list logo
