Chris McDonough wrote:
Chris McDonough wrote:
Off the top of my head, another way to think of this *might* be to say
that the 'dict access' is basically looking up a *named* utility
providing a very generic marker interface, e.g.
zope.component.interfaces.IUtility or even just
Chris McDonough wrote:
OK after rereading this, I think we may be massively overthinking this. The
above is getting kinda silly. I can't think of a use case where being able
to
alternate between:
reg.utils['root_factory']
and
reg.getUtility(IAnonymousUtility,
Log message for revision 105589:
Added IPubBeforeAbort event to mirror IPubBeforeCommit in failure scenarios.
This event is fired just before IPubFailure, but, crucially, while the
transaction is still open.
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U
Log message for revision 105590:
Be a bit more forceful about aborting the transaction
Changed:
U Zope/branches/2.12/src/ZPublisher/Publish.py
-=-
Modified: Zope/branches/2.12/src/ZPublisher/Publish.py
===
---
Leonardo Rochael Almeida wrote:
Wouldn't it be better to just move IPubFailure before the abort? Is
there a reason for subscribing to such an event which would required
the transaction to be aborted already? I can see the usefulness of the
transaction being already doom()ed before this event,
Hi,
In Zope 2.12 ZPublisher we have a good set of events now, which provide
useful hooks for modifying the response before or after publication.
However, I'd like to add one more. ;-)
Basically, we have IPubFailure, but this is sent *after*
transaction.abort() and endInteraction(). This means
Martin Aspeli wrote:
Hi,
I'm trying to turn the results of a test run using zope.testing
(zc.recipe.testrunner) into a JUnit compliant XML format so that I can
graph it with Hudson (a continuous integration tool).
Are there any hooks in zope.testing to write reporting to a file?
I
Log message for revision 105503:
Avoid possible errors on test tear-down in Products.Five.fiveconfigure's
cleanUp() function if Products.meta_types has not been set
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/Products/Five/fiveconfigure.py
-=-
Modified:
Martin Aspeli wrote:
Hi,
Something has changed in Zope 2.12 that is causing tests that use
PlacelessSetup's tearDown() with Five to fail:
Error in test
/Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../autoform.txt
Traceback (most recent
Hi,
What's the reasoning behind having both a content_icon and an icon_expr
property on FTIs in CMF 2.2?
Apart from being really confusing, it seems that DynamicType.getIcon()
returns fti.getIcon() (with some mangling), which returns self.content_icon.
Hence, if you set an icon with icon_expr
Hi,
Something has changed in Zope 2.12 that is causing tests that use
PlacelessSetup's tearDown() with Five to fail:
Error in test
/Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../autoform.txt
Traceback (most recent call last):
File
Adam Groszer wrote:
Hello,
After quickly glancing over plone.behavior it seems more like
something to extend a schema, and does it solve the problem of new
properties -- new schema -- change everything around it?
What I need is to be able to change schema properties per site. And
Chris Withers wrote:
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions'
extension. This prints the picked versions with some explanation about
what required them, either to a file or to the console. This is a useful
sanity check: if you see
Jim Fulton wrote:
On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli optilude+li...@gmail.com
wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen faas...@startifact.com
wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas
Hanno Schlichting wrote:
On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen faas...@startifact.com
wrote:
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions'
extension.
Does that make sense? After all, if we say allow-picked-version is
false
Martin Aspeli wrote:
Right, sorry, I must've been tired when I read this. In my mind, I read
it as disallow-picked-versions = false. :)
No, I'm not crazy after all. The thread is about *removing*
allow-picked-versions=false i.e. allowing versions to be picked. I
don't not hate those double
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver tseaver at palladion.com writes:
There is no way to tell the difference between a WebDAV GET and a
normal browser GET, period: the specs explicitly, deliberately
overload the GET verb
Benji York wrote:
On Wed, Oct 7, 2009 at 1:26 PM, Thomas Lotze t...@gocept.com wrote:
I just noticed that zope.testrecorder, which is listed in ztk.cfg as an
included package, imports from Globals, OFS, AccessControl and
Products.PageTemplates. This looks to me as if zope.testrecorder
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we use a different name? 'content type' to me sounds
like CMS-y functionality. We have interfaces like
Hanno Schlichting wrote:
On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we
Martijn Faassen wrote:
We could investigate two options:
* just removing that code that remove proxies and sees what happens to
significant Zope 3 code bases. Risky.
* alternatively, putting in an optional dependency on zope.security in
zope.component. If zope.security proxy is
Tres Seaver tseaver at palladion.com writes:
There is no way to tell the difference between a WebDAV GET and a
normal browser GET, period: the specs explicitly, deliberately
overload the GET verb.
Hence the IANA-assigned WebDAV source port[1] (9800) (which *we*
requested) in order to
Hi,
Following an earlier discussion on this list, I've made changes to
zope.filerepresentation to incorporate two new interfaces, IRawReadFile
and IRawWriteFile. These allow file representation adapters which behave
like Python standard library 'file' objects. This in turn allows
Fabio Tranchitella wrote:
Hello,
* 2009-10-05 12:15, Martin Aspeli wrote:
Would anyone mind making a 3.5.1 release, or else give me PyPI rights so
that I can do it myself.
Shouldn't this be 3.6.0?
I don't care one way or the other. 3.6.0 is fine by me.
Martin
--
Author
Hi,
In my travails through the ZPublisher and WebDAV, I've come up with
another fun thing.
As far as I can tell, traversal via acquisition doesn't make any sense
for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then
traversal to /bar/foo over WebDAV should not acquire /foo and
Martin Aspeli wrote:
Martin Aspeli wrote:
Martin Aspeli wrote:
Hi,
In my travails through the ZPublisher and WebDAV, I've come up with
another fun thing.
As far as I can tell, traversal via acquisition doesn't make any sense
for a WebDAV request. If I have /foo and /bar, but not /bar/foo
Shane Hathaway shane at hathawaymix.org writes:
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
Hi,
I came across this trying to implement WebDAV support for some content in Zope
2.
The ZPublisher will always traverse to the return value from 'browserDefault()'
(either from a custom IBrowserPublisher adapter, or the DefaultPublishTraverse
object hardcoded in ZPublisher.BaseRequest) when
Andreas Jung wrote:
I am pleased to announce the launch of a new website dedicated to the
Zope 2 application server:
zope2.zope.org
This site gives the Zope 2 application a much better representation on
the web (which was more than necessary after having lived for years
Hanno Schlichting wrote:
On Thu, Oct 1, 2009 at 2:13 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Hanno Schlichting wrote:
Is there any reason to invent a new API and not just use Python's file API?
I don't know. IReadFile and IWriteFile have been around for ever and are
used
Hi,
I'm doing some work with WebDAV representations in Zope 2, among other
things, and I'm trying to see if we should use zope.filerepresentation
as the central abstraction for file read/write operations.
However, I find myself lacking a couple of things:
1) A way for an IReadFile to return
Hanno Schlichting wrote:
Is there any reason to invent a new API and not just use Python's file API?
I don't know. IReadFile and IWriteFile have been around for ever and are
used by a number of things in Zope. They have read(), write() and
size(). The first two are on file, the last one
Jens Vagelpohl wrote:
On Sep 24, 2009, at 15:16 , Maurits van Rees wrote:
Personally, I am the maintainer of Products.Poi. It will take more
than one bottle of whisky to convince me to rename that. ;-)
Personally, I believe most product authors who have a real Zope 2
Product but chose
Hi,
- What is the current version of ZTK? 1.0? 1.0-something? 3.5? Note
that docs.zope.org/zopetoolkit talks about 3.5.
- What is the canonical location of a ZTK KGS? I'm locking for a
buildout [versions] block in particular.
- What is the plan for Zope 2.12 final? Is it going to rely
Gerhard Weis wrote:
Hi,
Sorry if this is the wrong list, but as plone.z3cform is in the
zope-svn. I thought it may be Ok.
There is a small problem in plone.z3cform. The class
plone.z3cform.fieldsets.extensible.ExtensibleForm has a class attribute
groups, which is changed by the
Christian Theune wrote:
On 08/01/2009 01:35 AM, Godefroid Chapelle wrote:
Sidnei da Silva wrote:
On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
Unfortunately, I've got other packages that depend on a newer
zope.testing (specifically,
Sidnei da Silva wrote:
On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
Unfortunately, I've got other packages that depend on a newer
zope.testing (specifically, collective.testcaselayer). But I thought
zope.testing aimed to be able to run any valid tests, so it
Hi,
I'm running the plone.z3cform tests in a Zope 2.10 instance with
zope.testing 3.8 installed.
All other tests seem to work OK, but with plone.z3cform's tests, I get:
$ ./bin/instance test -s plone.z3cform
Running tests at level 1
Running plone.z3cform.testing_zcml_layer tests:
Set up
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi,
I'm running the plone.z3cform tests in a Zope 2.10 instance with
zope.testing 3.8 installed.
All other tests seem to work OK, but with plone.z3cform's tests, I get:
$ ./bin/instance test -s
Hi,
It seems that an integration test written using ZopeTestCase (and
PloneTestCase) does not support using zope.security.checkPermission().
The problem is that the interaction threadlocal isn't set up, so you get
an AttributeError.
It's easy to fix: just call
Hanno Schlichting wrote:
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate
places in Zope2.
For example event.zcml registering events for OFS items, should live
in the OFS package. i18n.zcml setting up stuff for the request or the
publisher should live in the
Hanno Schlichting wrote:
On Sun, Jul 26, 2009 at 5:21 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
The problem is that the interaction threadlocal isn't set up, so you get
an AttributeError.
It's easy to fix: just call Products.Five.security.newInteraction()
before the test is run.
Wichert Akkerman wrote:
On 6/30/09 7:03 PM, Stephan Richter wrote:
It is needed for the latest-versions script as this parses XML. I consider
lxml pretty much the standard tool to do XML in Python these days. Who is not
using lxml?
I suspect the majority of people who use OSX as their main
Hi,
Is there any documentation on zope.proxy other than the test? I don't
speak C anymore. :)
Basically, I'm curious if it would be possible to implement translation
proxies that would allow getting and setting translated values for
certain fields.
Cheers,
Martin
--
Author of `Professional
Hi Christian,
Thanks for this!
Have a look at the attached file, it contains the code that I extracted
from a project in a hurry, but if the approach sounds reasonable to you,
I'd be happy to put that into SVN.
Can you tell me a bit more about how this is hooked into publication?
Where do
Patrick Gerken wrote:
Hello,
I am a bit confused about self.request and self.REQUEST.
Can anybody point me to an explanation of the different tasks that both
have?
Googling for request vs REQUEST is not helpful...
D'oh! :-)
REQUEST is a Zope2-ism. When you do self.REQUEST somewhere, you
Maurits van Rees wrote:
Adam GROSZER, on 2009-05-24:
Hello,
Following just happened. The project has KGS 3.4 versions as a base,
locally I wanted to override lxml to = 2.1.1.
[...snip...]
extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
versions = versions
[versions]
lxml
Hi,
So, we determined that OFS.Traversable's unrestrictedTraverse()
shouldn't grow support for IPublishTraverse, which is fair enough. We're
now using an ITraversable adapter instead (++namespace++).
However, we found another inconsistency. In URL traversal, this works:
Jan Hackel wrote:
Some days ago I ran into the same problem, and have been pointed to this
thread. Maybe you are interested in my solution. It's ugly, but I needed it
for a test-case, where I wanted to access
@@plone_context_state/is_view_template:
from ZPublisher.HTTPRequest import
Hi,
There's currently a funny inconsistency in Zope's Traversable class. If
you have a URL like http://localhost:8080/path/to/@@aview/foo, and
@@aview implements IPublishTraverse (and, I presume, if there's a custom
IPublishTraverse adapter for any other path component), URL traversal
will
Tres Seaver wrote:
The burden of proof *is* the work you just signed up the preserve
2.4 group for: monitoring the packages they care about for things
which break under 2.4, and proposing 2.4-compatible fixes.
Sure. That's different to saying officially that ZTK does not support
Python 2.4,
Martijn Faassen wrote:
Hey,
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for
new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse,
because
Lennart Regebro wrote:
On Tue, May 5, 2009 at 11:55, Martin Aspeli optilude+li...@gmail.com wrote:
We've had some more discussions about this and the Plone release
schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support,
it will effectively render it inaccessible to Plone users
Martijn Faassen wrote:
As I pointed out, it is effectively inaccessible for Plone users anyway,
as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3
libraries just like that and expect anything to work.
Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access
Martijn Faassen wrote:
So I see two responses for Plone developers:
* they know that they need new versions of zope.app.container and
zope.app.component too and require people to upgrade those too. This
might work fairly well, but does require the upgrade of more than just a
*few*
Chris Withers wrote:
plohn.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
Hi folks,
I've written a small Google App Engine application to help manage and
publish buildout configuration that provide a known good [versions] block.
I'm not sure this approach is good, and the application is not well
tested, but it may be of interest to some people here.
Martijn Faassen wrote:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope
Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave
vaguely as we *still* don't have a canonical list) only have to work in
Python 2.5 (and preferably 2.6), not Python 2.4
Gary Poster wrote:
I'm concerned about the state of the zc.buildout template recipes. I
want one. I want some one-off files, specific to a certain project,
for which writing a standalone recipe feels very heavy.
Here are the template recipes I found:
collective.recipe.template
Uli Fouquet wrote:
In the beginning my code should go into collective.recipe.template
itself (Wichert agreed), but I wasn't granted committer access to the
collective repository yet. Of course I requested to be approval and
waited for weeks, but nothing happened.
I'm sorry to hear that! In
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if
we get the kind of dependency isolation we're talking about, I'd wager
that quite a few packages would work
Andreas Jung wrote:
On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if
we get the kind of dependency
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Martin Aspeli wrote:
The Plone 3.x series will stay on Python 2.4 for a long time yet, so
this would be very disappointing. I can understand it if the maintenance
burden becomes large
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver wrote:
Thinking further on this: there is actually not much shiny about the
ZTK: it is going to be equivalent to a cut-down, dependency-stripped,
bbb-cruft-sanded version of the packages
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId()
as the same, always? OFS.SimpleItem has some support for letting id and
name be the same, but the link is lost once both __name__ and id are
set. Why isn't __name__ just
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId()
as the same, always? OFS.SimpleItem has some support for letting id and
name be the same, but the link is lost once both __name__ and id are
set. Why isn't __name__ just a property that reflects self.id ?
Then, the
Stephan Richter wrote:
On Sunday 19 April 2009, Tres Seaver wrote:
-1. As a branding choice (as opposed to a technology), Zope 3 *is* a
dead-end: it implies a strategy (replacing Zope 2) which we no longer
believe in. I think the consequences of the brand confusion are hard
for those uf us
Martijn Faassen wrote:
Hey,
Martin Aspeli wrote:
[snip]
I do realise that this derails Maritjn's focus slightly, but I don't
think we've lost the idea that there may be value in maintaining a
larger KGS.
The whole idea of whatever-Zope 3-is-designated-as just being a larger
KGS
Martijn Faassen wrote:
If we want to do this right we need to come up with a good way to get
the message out.
I think the only way you're going to manage to do that, is if you have a
website with a clear and unambiguous message on it.
It's like deja-vu all over again...
Martin
--
Author
Rob Miller wrote:
Gary Poster wrote:
This message seems like a reasonable start to me: Zope 3 has become
focused on supporting frameworks and applications, rather than trying
to be one itself. It is now called the Zope Toolkit. Parts of it are
used by Zope 2, Plone, Grok, Repoze.bfg,
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Log message for revision 99146:
Let the permission / directive auto-register permissions that don't
exist already
This kind of test is a poster child for why doctests with lots of
output
Hanno Schlichting wrote:
By now I count three people using Zope 3 for a small number of projects.
But none of them seems to have the resources to continue the maintenance
or future development of Zope 3.
Whilst you're absolutely right, just a word of warning: a lot of people
do not read
Martijn Faassen wrote:
Hey,
Martin Aspeli wrote:
[snip]
- In ZCML (or a grok.require() directive) use the Zope 3 name
Grok also has a grok.Permission you can subclass, and those subclasses
can also be passed to grok.require().
I know, but I kind of consider creating permissions
Log message for revision 99145:
Make the set_attributes and set_schema options to class ...require ...
//class issue a warning rather than throw an exception. Whilst the concept
doesn't make much sense in Zope 2, it's desirable to be able to re-use existing
packages that do declare such
Log message for revision 99146:
Let the permission / directive auto-register permissions that don't exist
already
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/Products/Five/permissions.zcml
U Zope/trunk/src/Products/Five/security.py
U
Dieter Maurer wrote:
Martin Aspeli wrote at 2009-4-12 18:31 +0800:
Finally, there is not total parity between Zope 2 security and Zope 3
security. Zope 2 cannot protect 'property set', for example.
Since Zope 2.8, Zope 2 could in principle -- and until quite recently
I thought
Martin Aspeli wrote:
I've now implemented 1 and 2 on trunk, since they seem pretty
non-controversial.
1) Use an event handler to ensure that any permission / declared in
ZCML actually creates a valid, Zope 2 permission. I have working code
for this here which we could put
Hermann Himmelbauer wrote:
-1 from my standpoint. Two of my projects are fully based on the Zope 3
server, and switching to something else would be quite some pain.
FWIW, I think you're absolutely right. We can't just declare it dead
because it is convenient to our goal of having clearer
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
I've not done this yet:
3) Change the Permission class in AccessControl so that it tries to
look up an IPermission utility and use the title of that utility as the
permission name, falling back
Hi all,
For a while now, people have had to contend with two ways of doing
certain things, depending on whether the code they are working with is
in Zope 2 land or Zope 3 land. We're getting closer to a world where
people don't need to be so intimately aware of the differences,
especially
Stephan Richter wrote:
On Thursday 09 April 2009, Martin Aspeli wrote:
Clearly, I'm getting too new a version of RestrictedPython, but this is
running against the 3.4 KGS, so I don't see how that could really happen.
This is not a problem. Ignore those errors as they happen in the Python 2.6
Adam GROSZER wrote:
Hello,
I would add TEMPORARYLY (for testing) the KGS to buildout.cfg:
[buildout]
extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
versions = versions
develop = . benchmark
parts = test checker coverage-test coverage-report docs i18n benchmark python
Wichert Akkerman wrote:
Previously Shane Hathaway wrote:
discussion type=bikeshed
Tres Seaver wrote:
WRT the Framework name: framework is a misleading name for the
collection of packages salvaged from the new Coke effort: it is
actually a *bunch* of frameworks, in the classic software
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2
release to Zope 4. That reflects the large refactoring that is being
done to clean up the codebase and fully eggify Zope. There are enough
Hi,
I just tried to check out the new 1.9.x branch of z3c.form (thanks
Stephan!), but it won't build with Python 2.4 (I need this to work with
Plone, so 2.4 is a must):
$ ./bin/buildout
Develop: '/users/optilude/Development/Plone/Code/Products/z3c.form/.'
Unused options for buildout:
Martijn Faassen wrote:
Let's talk about Zope Classic and see whether renaming Zope 2 to that is
a step we can realistically take in the near future. Who is in favor of
that?
-100
Zope 2 is an incredibly established name. It's been around forever.
Renaming something that has been out there
Martijn Faassen wrote:
Hey,
Okay, in the interests of making this discussion go quickly, there has
been enough negative feedback about renaming Zope 2 to think we have no
realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2
release to Zope 4. That reflects the large refactoring that is being
done to clean up the codebase and fully eggify Zope. There are enough
changes to warrant a new major version bump.
-100 again.
Hi,
Today, I found a bug in ChoiceTerms: it will only bind the field if
field.vocabulary is None, which breaks uses of an IContextSourceBinder.
I thought to fix that in svn, but there's no 1.9.x branch, and 2.0
(trunk) is a very different beast.
Tracking 2.0 trunk is not an option right now.
Chris Rossi wrote:
from zope.interface import Constant
class IHttpResponse(Interface):
Models an HTTP 1.1 response.
HTTP_OK = Constant(200 Ok, An HTTP Ok response.)
HTTP_NOT_FOUND = Constant(404 Not Found, An HTTP Not Found response)
status = Attribute(HTTP status
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Zope community, I am pleased to announce the creation
of the Zope 4.0 project. After extensive discussion with the Zope
wizards in conclave at PyCon 2009, the new project's website has been
launched:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo)
def some_function(context)
pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface):
Stephan Richter wrote:
On Tuesday 17 March 2009, Martijn Faassen wrote:
If a package defines a *lot* of ZCML, we will have to wonder about the
purpose of the package (is this really a library-like package or more
like an application defining a UI or something?), and we'll have to
think about
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 1:17 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
As mentioned earlier: use buildout. easy_install support has no high
priority right now.
Whilst I understand that we don't have the capacity to test all
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses zc.relationship.shared.Container, and stores
a
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular
Martin Aspeli wrote:
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2
Hi Gary,
zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation
code for backwards compatibility.
I see. But 2.0dev on pypi isn't?
What's the story behind zc.relation and the evolution of zc.relationship?
You guys are the main clients for zc.relationship at this point, I
Hi Gary,
Thanks for being so helpful!
What's the difference between 1.1.1 and 2.0dev on pypi?
I intended that 1.1.1 would simply make the absolutely minimal changes
necessary for you to be able to use the 1.1 branch. It would not have
any of the 2.x changes at all.
But we're saying
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd be willing to fix.
201 - 300 of 482 matches
Mail list logo
