[Zope3-dev] Re: Better default namechooser
On 2007-10-12 10:21:28 +0200, Philipp von Weitershausen [EMAIL PROTECTED] said: Christian Zagrodnick wrote: I constantly run into the fact that the default namechooser in Zope 3 is too dumb. Does anybody object in making it a little more smart? That is: * replace all non us-ascii and otherwise harmful chars by something useful (base-form or alike) Why would you want to replace all non-ASCII characters by default? Names of contained objects can be unicode, and URLs can contain unicode segments as well (encoded as UTF-8). Having the default namechooser make the arbitrary decision of disallowing everything that's not ASCII seems quite arbitrary. Of course they can. But looking from the browser/user perspective any URL containing %XY looks just strange. Also those urls are often garbled by mail programms or alike. * replace spaces by - or _ Again, object names may contain spaces. I don't understand why this should be the *default* policy. If you need this kind of stuff, then I suggest you write your own namechooser; it's quite trivial. Of course it's trival. Only that I've *always* had to replace it with something else for every single project so far. So from my perspective the default might work but is sort of useless. But well, maybe it's not work the effort since we've eggs now. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Better default namechooser
Hey, I constantly run into the fact that the default namechooser in Zope 3 is too dumb. Does anybody object in making it a little more smart? That is: * replace all non us-ascii and otherwise harmful chars by something useful (base-form or alike) * replace spaces by - or _ -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML-Directive for DirectoryResource factories?
On 2007-10-05 14:30:14 +0200, Fred Drake [EMAIL PROTECTED] said: Meant to send this to the list... On 9/18/07, Christian Zagrodnick [EMAIL PROTECTED] wrote: The only thing is, no I'm not going to register every file in ZCML. I want to use the zc.resourcelibrary. The follwoing makes it possible, but it's not too nice to have that somewhere in the code: (zope.app.publisher.browser.directoryresource. DirectoryResource.resource_factories['.js']) = ( z3c.zrtresource.zrtresource.ZRTFileResourceFactory) I'd rather have a ZCML-directive to do that. Would that fit into zope.app.publisher? I think the right approach would be to make the new directive a sub-directive of the resourcelibrary and/or the resourcedirectory directive. Then there could be a separate extension - type map for each directory of resources. An alternative would be to allow the library or directory directive to refer to a map defined elsewhere (say, in Python), making it easier to re-use maps. This makes a lot of sense to me, since the provider of each pile of resources knows what they put in it and what the processing requirements are. A global map seems like a bad idea here. You are right, a local map would be much better. I basically came up with the global one, because its already there. But local sounds good. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ChoiceField and the use of sources/vocabularies
On 2007-10-01 21:41:36 +0200, Philipp von Weitershausen [EMAIL PROTECTED] said: Christian Theune wrote: Zagy and I are trying to make z3c.form compatible with sources. Shrug... Why wouldn't it be compatible already? Shouldn't the widget abstract everything away? We had to investigate zope.schema for that and found the mess of vocabularies and sources that is still around. Here are some facts we found: - The Choice field has an attribute `vocabulary` which it says to be an 'IBaseVocabulary' object. - Reading the code of the choice field turns out that the actual contract is an 'ISource'. Actually it behaves as follows: choice.vocabulary is either ISource or None if choice.vocabulary is None, choice.vocabularyName will not be none, but that's an internal. If the field is *bound* bound.vocabulary will be ISource in any case. - Most client code working against the `vocabulary` attribute actually assumes it to be an IIterableVocabulary. That should be fixed then. Adaption to some iteration interface seems sensible. - The vocabulary code is badly entangled and mixes up concepts that sources get right. - Widgets for the choice field have to react differently to sources and vocabularies. We think: - The contract for the `vocabulary` attribute should be ISource. +1 Making a contract more loose than it already is is always possible. - Client code (e.g. a widget) should adapt the generic source it gets to a more specific and richer interface like IIterableSource. - Widgets for the choice field shouldn't have to care for two different things that the source could be. - Vocabularies ought to die. No can do. But perhaps we can keep the amount of BBB dance as small as possible. Vocabularies are just special ISource implementations. They should work, even if they mix stuff. Mixing stuff isn't forbidden... Well ... producing terms is so boring I'd not want to do it ;) We'd love to remove all traces of vocabularies from zope.schema and it more clear how to use sources. +1 to making sources more straightforward. Actually you cannot make sources more straightforward as zc.sourcefactory made it. As deprecation has fallen out of favor, we wonder how to get rid of vocabularies. We definitely do not want to fork zope.schema. Would a sufficiently newer version (3.5, 4?) rectify breaking something in this way? I estimate that providing BBB is going to be a real pain. :/ So pain it is... So, when the contract is ISource, a widget would need to adapt choice.vocabulary to IIterableSource to get the values. For terms it should multiadapt (choice.voabulary, request) to zope.app.form.browser.interfaces.ITerms. There probably could be standard adapters for: IIterableVocabulary - IIterableSource IVocabularyTokenized - ITerms (using multi adapter of (vocab, request)) We also might think about not using choice.vocabulary but choice.source ... but that might break quite a lot more -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pagelet and LayoutTemplate recursion
On 2007-09-26 17:30:21 +0200, Stephan Richter [EMAIL PROTECTED] said: On Wednesday 26 September 2007 11:23, Christian Zagrodnick wrote: Ok. Would this break anything when z3c:template suddenly uses a different interface? I don't think so, because this is not used in Python code usually. Thanks for fixing this!! I released a z3c.tempalte 1.1a1 to downloads.zope.org and made z3c.pagelet trunk depend on it. So that problem should be gone. Would somebody test it and release it on pypi? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Pagelet and LayoutTemplate recursion
Hi, there is a recursion problem with Pagelets and layout templates when you don't register a template for the pagelet. A layout template could be registered as follows (from z3c.formdemo): z3c:layout for=* layer=z3c.formdemo.layer.IDemoBrowserLayer template=template.pt / This registers an adapter providing ILayoutTemplate. The BrowserPagelet's render method retrieves the template for the pagelet's contents (i.e. not the outer wrap) as follows: template = zope.component.getMultiAdapter( (self, self.request), IPageTemplate) The problem is, that ILayoutTemplate is derived from IPageTemplate. This is why the pagelet tries to render its contents with the layout template. I'm not sure what to do about this. a) Explicitly check that the template is *not* an ILayoutTemplate in BrowserPagelet.render b) make z3c:template use another interface which is also derived from IPageTemplate and use the new interface in BrowserPagelet.render. c) ... ? Comments, remarks? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: skin support for xmlrpc
On 2007-09-15 17:35:20 +0200, Roger Ineichen [EMAIL PROTECTED] said: Hi Christian Betreff: [Zope3-dev] Re: skin support for xmlrpc On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said: On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote: If you register views for a base request type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? If I understand the concept correct. This is a builtin backdoor. Doesn't this allow to bypass the Apache rewrite rule? With: http://www.foobar.com/++api++xmlrpc/doSomething If the rewrite rule in Apache is: RewriteRule (/?.*) http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1 [P,L] Or does the ++api++ namespace recognize the skin? Which means the url rewritten url is. With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething A way to avoid this is to allow applying a skin / request type only once. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 2007-09-18 19:51:43 +0200, Dieter Maurer [EMAIL PROTECTED] said: Christian Zagrodnick wrote at 2007-9-18 08:35 +0200: On 2007-09-16 09:03:47 +0200, Dieter Maurer [EMAIL PROTECTED] said: Ok, then I suggest: * Provide an IRequestType interface in zope.publisher Does this name sound wrong? It suggests the the interface has to do with request types, maybe browser, xmlrpc, ... It that what we want? IAPIType? IApi? IHTTPApiType? /me is confused again. :/ Me, too. Terms are very important for me -- and I could not understand RequestType. What should it mean that zope.publisher provides an IRequestType. What types are these? Do you mean types in the sense of browser requests, xml-rpc requests, ftp requests, ... or something else? I figured that what I actually mean is IHTTPRequestType, which is a generalisation of IBrowserSkinType for all HTTP requests. Does this make sense? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pagelet and LayoutTemplate recursion
On 2007-09-26 17:01:45 +0200, Stephan Richter [EMAIL PROTECTED] said: On Wednesday 26 September 2007 10:19, Christian Zagrodnick wrote: there is a recursion problem with Pagelets and layout templates when you don't register a template for the pagelet. Yep, nasty, isn't it? The problem is, that ILayoutTemplate is derived from IPageTemplate. This is why the pagelet tries to render its contents with the layout template. I'm not sure what to do about this. Roger and I discussed this issue over the weekend and just have not had the time to work it out. a) Explicitly check that the template is *not* an ILayoutTemplate in BrowserPagelet.render Good solution. :-) b) make z3c:template use another interface which is also derived from IPageTemplate and use the new interface in BrowserPagelet.render. Also a good solution. :-) I think both approaches are fine. Roger and I had decided on (b) when we discussed it. Ok. Would this break anything when z3c:template suddenly uses a different interface? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 2007-09-15 17:35:20 +0200, Roger Ineichen [EMAIL PROTECTED] said: Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? If I understand the concept correct. This is a builtin backdoor. Doesn't this allow to bypass the Apache rewrite rule? With: http://www.foobar.com/++api++xmlrpc/doSomething If the rewrite rule in Apache is: RewriteRule (/?.*) http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1 [P,L] I suppose you're right. Even though I wonder if you couldn't also say http://www.foobar.com/++skin++GetMeThere/doSomething to get another Browser-Skin. But you're right, that you must never get a XML-RPC method with an BrowserRequest. Or does the ++api++ namespace recognize the skin? Which means the url rewritten url is. With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething But then, do we need to regsiter the ++api++ for each layer? I guess this is not what you are asking for. right? No, it's quite the same as with skins, i.e. You can concider one Layer as a Skin or aggregate multiple Layers into one skin. My main issue on this thread is allways the same: Skins are a security layer. And don't bypass them, then this let us use views which we don't like to provide in a layer/skin. Right. But it's not *really* about security. For a browser you usually define how a web page looks like and thereby of course define what's possible and what not. For XML-RPC you define the API. But ultimately this is not security. Security is achieved by the security proxy. You must take care that an unprivileged user cannot access a method which he should is allowed to. And you do that via the security engine. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 2007-09-16 09:03:47 +0200, Dieter Maurer [EMAIL PROTECTED] said: Christian Zagrodnick wrote at 2007-9-15 12:34 +0200: ... Ok, then I suggest: * Provide an IRequestType interface in zope.publisher Does this name sound wrong? It suggests the the interface has to do with request types, maybe browser, xmlrpc, ... It that what we want? IAPIType? IApi? IHTTPApiType? /me is confused again. :/ -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ZCML-Directive for DirectoryResource factories?
Hoi, I was just playing with z3c.zrtresource a bit and it seems to be quite a nice approach to (for instance) set the server URL in javascript. The only thing is, no I'm not going to register every file in ZCML. I want to use the zc.resourcelibrary. The follwoing makes it possible, but it's not too nice to have that somewhere in the code: (zope.app.publisher.browser.directoryresource. DirectoryResource.resource_factories['.js']) = ( z3c.zrtresource.zrtresource.ZRTFileResourceFactory) I'd rather have a ZCML-directive to do that. Would that fit into zope.app.publisher? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Transaction bound cache
On 2007-09-17 16:04:12 +0200, Jim Fulton [EMAIL PROTECTED] said:
No, that would introduce a dependency on zodb. I suggest a separate package.
I figured that I latetly added something to zope.cachedescriptors which
was adding a dependency to ZODB quite unnecessaryly. Removed the
dependency now again and will create another package for the
transaction bound cache.
On Sep 17, 2007, at 6:03 AM, Christian Zagrodnick wrote:
Hi
i've got a very simple transaction bound cache implementation. That
is the cache gets invalidated on transaction end.
It's used like this:
class Foo(object):
data = TransactionBoundCache('_v_store_it_here', dict)
where `dict` is the cache factory.
Shall I add this to zope.cachedescriptors?
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Transaction bound cache
On 2007-09-18 11:38:47 +0200, Christian Zagrodnick [EMAIL PROTECTED] said: On 2007-09-17 16:04:12 +0200, Jim Fulton [EMAIL PROTECTED] said: No, that would introduce a dependency on zodb. I suggest a separate p ackage. I figured that I latetly added something to zope.cachedescriptors which was adding a dependency to ZODB quite unnecessaryly. Removed the dependency now again and will create another package for the transaction bound cache. I created gocept.cache: http://pypi.python.org/pypi/gocept.cache/ and added it there. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Transaction bound cache
Hi
i've got a very simple transaction bound cache implementation. That is
the cache gets invalidated on transaction end.
It's used like this:
class Foo(object):
data = TransactionBoundCache('_v_store_it_here', dict)
where `dict` is the cache factory.
Shall I add this to zope.cachedescriptors?
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: New Contributor References
On 2007-09-12 15:32:42 +0200, Jim Fulton [EMAIL PROTECTED] said: Lately, I've started being a bit more careful about accepting new contributors. In particular, I'm requesting that new contributors provide the name of an existing contributor who is familiar with them and their work. I (or someone) really need to add this to the contributor agreement, but I'm not sure when I'll have time. Now, It's taking a fair bit of time writing new contributors to ask for references. I encourage folks to request committer access, I just ask that people provide the names of one or more existing committers who can vouch for them. I think that is good. It's just like noting references on a job application. Sobody you (as employer) can call/mail and ask about the applicant. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said: On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote: If you register views for a base request type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: skin support for xmlrpc
On 13.09.2007, at 18:07, Roger Ineichen wrote: Hi Betreff: [Zope3-dev] Re: skin support for xmlrpc On 13.09.2007, at 17:28, Philipp von Weitershausen wrote: Christian Theune wrote: Let me propose a change: 1. We revert the change. Any news on this? Yes. Over the last few days I pondered about how to do it without xmlrpc layers. But there doesn't seem to be a way nice and easy way. So I will need to implement the layer support in a different package. The revert will be done till monday, maybe already tomorrow. Sorry for the delay. Anyway, could somebody who had an error with that tell me what the problem was? I just heard we had a problem. Why revert? We need layers in every kind of context, request adapter registration because it's the concept which permission get registered in different projects on a single server sharing packages. The problem is simple, XML-RPC has used the IBrowserRequest and now it uses the IXMLRPCRequest. This is why the XML-RPC views in different projects don't work anymore. This means the XML-RPC uses a browser request which is bad because it enables the views everywhere. No no. XML-RPC did use IXMLRPCRequest before. All I added was the IXMLRPCSkinType which did not exist. What I also changed is the ++skin++ traverser which was registered for * instead of IBrowserRequest. But I consider the old behaviour a bug since skins were only valid with IBrowserRequest. The solution is to provide the request interface which was the default before the changes. But don't take the option way to use other request interface then the default for registration. I'll need it. Because I'll take care on security and don't like to register everything on whatever. Before I'll revert the layer-support will be there in a third party package, probably using ++api++. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 PGP.sig Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: skin support for xmlrpc
On 14.09.2007, at 08:49, Fred Drake wrote: On 9/14/07, Christian Zagrodnick [EMAIL PROTECTED] wrote: Before I'll revert the layer-support will be there in a third party package, probably using ++api++. Better to be specific than general when it's for a specific type of request; why not ++xmlrpc++? Unless ++api++ is for more than XML-RPC support; perhaps it should be for IHTTPRequest? I'd actually rather avoid a proliferation of ++namespace++ usages myself, and prefer ++api++ for IHTTPRequest. So you're suggesting using ++api++ to choose the request type for all IHTTPRequests. That's fine for me. I just wonder why I should remove the skin support for XML-RPC since that is just choosing the request type... /me is confused. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 PGP.sig Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 13.09.2007, at 17:28, Philipp von Weitershausen wrote: Christian Theune wrote: Let me propose a change: 1. We revert the change. Any news on this? Yes. Over the last few days I pondered about how to do it without xmlrpc layers. But there doesn't seem to be a way nice and easy way. So I will need to implement the layer support in a different package. The revert will be done till monday, maybe already tomorrow. Sorry for the delay. Anyway, could somebody who had an error with that tell me what the problem was? I just heard we had a problem. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 PGP.sig Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
On 2007-08-24 07:55:08 +0200, Jodok Batlogg [EMAIL PROTECTED] said: hi christian, it seems like your recent changes to support skins in xmlrpc views =20 introduced some troubles. we spent several hours to debug not working xmlrpc views and finally =20 found that nailing the zope.traversing egg to 3.4.x resolved the =20 troubles. while looking at your changes we were wondering why you want to =20 support skins in xmlrpc views? for me, a xmlrpc call is a remote =20 procedure call and has to do nothing with skins. it's not yellow, =20 pink or orange and has no templates associated. can you explain your =20 use-case for this? Oh, thanks for the reminder, I completely forgot writing about that. Though I wonder what the problems were. The term skin is probably missleading but was taken to keep it simple. It's more an api-set. Usecase: Different API on the same server We have a lot XML-RPC methods defined for ISite which get all their data in. This is quite unlike one would register XML-RPC mehtods normally, but the clients using the interface are not sophisticated enough. Now there are different systems talking with Zope. The systems have some things in common, some not. One systems calls a method, say list_foo anonymous, while another needs to authenticate for list_foo. The idea is now to register list_foo for different layers/skins/api-sets. This could also be achieved by creating dummy model-objects and/or traversers, but would be much less understandable. What essentially happens is that the views are registered for different request types. Usecase: Authenticate Users depending on the skin As i said before there are different systems which need to authenticate. The systems have disjunctive sets of users with potentially the same login names. There needs to be a way to authenticate without guessing which set of users we're talking about. This could also be achieved by a custom traverser or namespace. As you can see, there is no usecase which can't be solved differently. But still we think that using the same system as skins for browser views is the right way to do that. We might want to talk about the naming though and call it api or alike. It probably would not be much of a problem to remove the skin things again and put it directly to the project or another third-party component. But it doesn't feel right. Now shoot :) Regards -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] __repr__ of ValidationErrors in zope.schema
Hi I'm implementing the getValidationErrors thingy right now and once again stumbled upon the ValidationErrors. Their __repr__ is all but useful. For instance TooSmall: TooSmall(8, 10) 8 10 Another sort of related issue is that you only get the __doc__ string when calling the .doc() method. Value is too small. doesn't help a lot. Something like The value 8 is too small. At least 10 is required. would be much more informative. What should we do about this? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Leak in zope.component?
Hi, I'm doing things wich z3c.zalchemy and trying to find out why my database connections are kept open even after unregistering everything. Given the following very simple test: import sys import zope.component import zope.interface class IUtil(zope.interface.Interface): ... pass gsm = zope.component.getGlobalSiteManager() utility = object() sys.getrefcount(utility) 2 gsm.registerUtility(utility, IUtil) sys.getrefcount(utility) 6 gsm.unregisterUtility(utility, IUtil) True sys.getrefcount(utility) # this fails 2 -- File /Users/zagy/development/z3c.zalchemy/src/z3c/zalchemy/tests/dispose.txt, line 17, in dispose.txt Failed example: sys.getrefcount(utility) # this fails Expected: 2 Got: 4 So there are now two more references than before register/unregister. Am I missing something? Or is it leaking somewhere? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Leak in zope.component?
On 2007-08-22 16:12:42 +0200, Jim Fulton [EMAIL PROTECTED] said: On Aug 22, 2007, at 8:16 AM, Christian Zagrodnick wrote: Hi, I'm doing things wich z3c.zalchemy and trying to find out why my database connections are kept open even after unregistering everything. Given the following very simple test: import sys import zope.component import zope.interface class IUtil(zope.interface.Interface): ... pass gsm = zope.component.getGlobalSiteManager() utility = object() sys.getrefcount(utility) 2 gsm.registerUtility(utility, IUtil) sys.getrefcount(utility) 6 gsm.unregisterUtility(utility, IUtil) True sys.getrefcount(utility) # this fails 2 -- File /Users/zagy/development/z3c.zalchemy/src/z3c/zalchemy/tests/ dispose.txt, line 17, in dispose.txt Failed example: sys.getrefcount(utility) # this fails Expected: 2 Got: 4 So there are now two more references than before register/ unregister. Am I missing something? Or is it leaking somewhere? Here's what I get with the trunk of zope.component: [EMAIL PROTECTED]:~/p/zope/component/trunk$ bin/py import sys, zope.component, zope.interface class IUtil(zope.interface.Interface): pass ... gsm = zope.component.getGlobalSiteManager() utility = object(); sys.getrefcount(utility) 2 gsm.registerUtility(utility, IUtil); sys.getrefcount(utility) 5 gsm.unregisterUtility(utility, IUtil); sys.getrefcount(utility) True 2 So I can't reproduce what you are seeing. Try adding: import gc; gc.collect() before your last getrefcount call. That doesn't change a thing. Could it be the testrunner having an eye on registrations? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Add function for schema validation in zope.schema
Hi,
zope.schema defines how a schema can be validated, defines errors and
provides a way to validate single fields.
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
validateSchema(IMySchema, myobject) [or alike]
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
Comments?
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
On 2007-08-20 14:59:52 +0200, Fred Drake [EMAIL PROTECTED] said:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
Yes, I like the idea.
Will add it with the exception as time comes by.
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] browser:page's for= can be class browser:menuItem can't
Hoi I just figured, that the browser:menuItem cannot be registered for classes. But you can with browser:page. I think if a browser:page can be registered for a class a menuItem should support this, too. Also a browser:page for=someclass menu=... / will break on getting the menu items because the implementation doesn't support classes. Should we fix that? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: zope.location/trunk/src/zope/location/location. added method quite like in zope.app.container.contained
On 2007-08-17 13:57:05 +0200, Christian Zagrodnick [EMAIL PROTECTED] said: Log message for revision 78902: added method quite like in zope.app.container.contained That should have been added `located` method quite like `contained` in zope.app.container.contained Changed: U zope.location/trunk/src/zope/location/location.py U zope.location/trunk/src/zope/location/location.txt -=- Modified: zope.location/trunk/src/zope/location/location.py === --- zope.location/trunk/src/zope/location/location.py 2007-08-17 11:48:10 UTC (rev 78901) +++ zope.location/trunk/src/zope/location/location.py 2007-08-17 11:57:04 UTC (rev 78902) @@ -44,6 +44,18 @@ object.__name__ = name +def located(object, parent, name=None): +Locate an object in another and return it. + +If the object does not provide ILocation a LocationProxy is returned. + + +if ILocation.providedBy(object): +locate(object, parent, name) +return object +return LocationProxy(object, parent, name) + + def LocationIterator(object): while object is not None: yield object Modified: zope.location/trunk/src/zope/location/location.txt === --- zope.location/trunk/src/zope/location/location.txt 2007-08-17 11:48:10 UTC (rev 78901) +++ zope.location/trunk/src/zope/location/location.txt 2007-08-17 11:57:04 UTC (rev 78902) @@ -75,9 +75,13 @@ from zope.location.location import LocationProxy l = [1, 2, 3] + ILocation.providedBy(l) +False p = LocationProxy(l, Dad, p) p [1, 2, 3] + ILocation.providedBy(p) +True p.__parent__ 'Dad' p.__name__ @@ -94,3 +98,36 @@ p.__doc__ == l.__doc__ True + +The `located` function +== + +`located` locates an object in another and returns it: + + from zope.location.location import located + a = Location() + parent = Location() + a_located = located(a, parent, 'a') + a_located is a +True + a_located.__parent__ is parent +True + a_located.__name__ +'a' + + +If the object does not provide ILocation a LocationProxy is returned: + + l = [1, 2, 3] + parent = Location() + l_located = located(l, parent, 'l') + l_located +[1, 2, 3] + l_located.__parent__ is parent +True + l_located.__name__ +'l' + l_located is l +False + type(l_located) +class 'zope.location.location.LocationProxy' -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.annotation dependency to zope.app.container.contained
On 2007-08-09 20:51:26 +0200, Philipp von Weitershausen [EMAIL PROTECTED] said: Roman Joost wrote: we're doing some dependency checking at gocept and I discovered that zope.annotation depends on zope.app.container in its factory. What shall we do with this dependency to zope.app.container? Moving this factory to zope.app is probably not the best solution. To be clear, zope.annotation doesn't depend on zope.app, it depends on zope.app.container which is its own package and egg (and in fact, zope.annotation's dependencies are refreshingly few). The real problem is that zope.app.container depends on a whole bunch of other things. The question is why. Okay, actually I think that zope.annotation uses IContained. This is just wrong but also results in an underspecification of IContained: class IContained(ILocation): Objects contained in containers. When you read it very carefully you figure that it actually says is that object.__parent__[object.__name__] would result in the object again. IContained states how you can get the object from the __parent__. ILocation doesn't do that. For the annotation factory using zope.location and ILocatable would be sufficient. So we could get rid of the zope.app.container dependency. We should be a bit more specific about the IContained interface. Does it make any sense to have an IContained object without __name__. I think not. Chaning that would make __name__ a required attribute on IContained. Comments? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.app.form/trunk/src/zope/app/form/browser/te FileWidget tries to be smarter about not deleting the currently stored content when the user did not upload a new file.
On 2007-06-26 22:41:25 +0200, Gary Poster [EMAIL PROTECTED] said: On Jun 23, 2007, at 6:38 AM, Christian Zagrodnick wrote: Log message for revision 76975: FileWidget tries to be smarter about not deleting the currently stored content when the user did not upload a new file. ... Modified: zope.app.form/trunk/src/zope/app/form/browser/textwidgets.py === --- zope.app.form/trunk/src/zope/app/form/browser/textwidgets.py 2007-06-23 10:25:23 UTC (rev 76974) +++ zope.app.form/trunk/src/zope/app/form/browser/textwidgets.py 2007-06-23 10:38:37 UTC (rev 76975) @@ -475,6 +475,11 @@ def _toFieldValue(self, input): if input is None or input == '': +# There was no input. With File-Upload this usually means that the +# value should *not* change. Let's try to get the old value. +content = self.context.context +if self.context.interface.providedBy(content): +return self.context.get(content) return self.context.missing_value try: seek = input.seek Hey. This has a couple of bugs, IMO. It might also be a misfeature, but I'm less sure about that. First, return self.context.get(content) assumes that this widget will be used on an edit form (not true for us). Second, if self.context.interface.providedBy(content): assumes that the schema field is part of an interface (not true for us). Hum. From that I make that there are not enough tests. :/ I figure that the .interface attribute doesn't seem to be part of any interface anyway. So in fact this is not a nice thing to do. Neither of these are valid assumptions generally for a form field, IMO. I'm also not sure about the semantics. Shouldn't this be handled more at the form level? I can see why you want to do this here, but it seems pretty gray, and I'm not sure how to solve the bugs in a sane and reliable way. No, thinking about it it's not the right way I did it. Basically I wasn't aware about the different conexts. In general I know that, but sometimes you're just blind :) I agree that this is a tricky problem, and it would be nice to solve it, but your solution is not correct for a generic form widget. The only suggestion I have ATM is to revert this, unfortunately, but I welcome other approaches that solve the issues I raised. Solving it on form level is of course possible but not really the thing you want to think about. I suspect there should be some 'i have not changed' marker value. There is some strange thing in zope.formlib.form.applyChanges preventing updates of the value already: def applyChanges(context, form_fields, data, adapters=None): ... for form_field in form_fields: ... name = form_field.__name__ newvalue = data.get(name, form_field) # using form_field as marker if (newvalue is not form_field) and (field.get(adapter) != newvalue): changed = True field.set(adapter, newvalue) return changed newvalue is not formfield? To me this does not make much sense. Why would I return self.context to indicate the value has not changed? Questions over questions :) -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: deprecate ++etc++site/default?
On 2007-06-19 14:46:55 +0200, Stephan Richter [EMAIL PROTECTED] said: On Tuesday 19 June 2007 06:16, Christian Zagrodnick wrote: as far as I am informed it's no longer suggested to put utilities etc. into the default package since the whole package mechanism was not the right idea. One point to change would be zope.app.appsetup.addUtility which puts the utilities into the default package. It should add the utilities directly to the site manager. What are the oppinions here? I have suggested this before, but back then we decided to leave things as they were. Maybe the time has come to change that. Having said that, this change would break a lot of code, including all opf my projects, since I do not use zope.app.appsetup.addUtility. Since we are not working with egg-based releases yet, BBB must be provided. Depending on how good the BB is, this could be an easy or very hard task. Just to make it clear: I don't want to take addUtility away. I want to change the behaviour of addUtility. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: deprecate ++etc++site/default?
On 2007-06-19 22:13:59 +0200, Bernd Dorn [EMAIL PROTECTED] said: On 19.06.2007, at 19:46, Philipp von Weitershausen wrote: Christian Theune wrote: I can't remember who I talked to about this who pointed out to me that, in most cases, you don't have to care about the `default` folder and can put the utilities that you don't want in content space just directly into the site manager. Due to that I don't see a reason for a `default` site-management folder inside the site manager. I never had the use-case for more than one package, but I'm also somewhat unsure what they really are about. I just re-read the doctests in zope.app.component and they only talk about the mechanics of the site managers and site-management folders. They give a vague hint that they can be used to logically organize your software. I don't think I'm going to organize my software in the ZODB, so I'm a bit puzzled at what that means. Site management folders had a meaning and incorporated machinery once. That's gone now. They're just dumb containers now. The 'default' thing is an artefact. It is totally possible to add your local utilities anywhere you want, they don't even have to be in a container as long as they're persisted in the registry. In the interest of removing cruft and making things more straight- forward for newbies, 'default' should be ripped out. In the interest of existing projects, however, BBB must provided. +1 I suggest a hack: We remove 'default' and from now on put utilities directly into the site manager. For BBB, we allow access to a 'default' subcontainer which is faked:: Let's get a site and look at its site manager: site = getSite() site_manager = site.getSiteManager() The site manager is empty or, in case of the root site manager, it has a few default utilities: list(site_manager.keys()) ['ErrorReportingUtility', 'ClientIDManager', ...] Even though there seems to be no 'default' folder anymore, it's still possible to get it: default_folder = site_manager['default'] list(default_folder.keys()) ['ErrorReportingUtility', 'ClientIDManager', ...] +1 (I imagine site_manager.__getitem__ simply returning self when key == 'default') -1 i think we should let people create a thing called 'default' if they want to, it just doesn't matter why not just raise a deprecation warning if no default folder is there and some code traverses default, but if an object is there with this name it should be alright because then the default folder was created in an old release or by intent. Right. I guess we should check if there is an object called default. If there is just don't do anything special. If there is not return self with deprecation warning. Note that adding a subitem called 'default' won't be allowed: site_manager['default'] = object() Traceback (most recent call last): ... Your -1 goes was for this part, was it not? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] deprecate ++etc++site/default?
Hi there, as far as I am informed it's no longer suggested to put utilities etc. into the default package since the whole package mechanism was not the right idea. One point to change would be zope.app.appsetup.addUtility which puts the utilities into the default package. It should add the utilities directly to the site manager. What are the oppinions here? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: zc.sourcefactory/trunk/src/zc/sourcefactory/browser/source.py fix typo
On 2007-06-08 14:56:02 +0200, Fred L. Drake, Jr. [EMAIL PROTECTED] said: Log message for revision 76498: fix typo Changed: U zc.sourcefactory/trunk/src/zc/sourcefactory/browser/source.py -=- Modified: zc.sourcefactory/trunk/src/zc/sourcefactory/browser/source.py === --- zc.sourcefactory/trunk/src/zc/sourcefactory/browser/source.py 2007-06-08 12:29:50 UTC (rev 76497) +++ zc.sourcefactory/trunk/src/zc/sourcefactory/browser/source.py 2007-06-08 12:56:01 UTC (rev 76498) @@ -53,7 +53,7 @@ class FactoredContextualTerms(FactoredTerms): -A terms implementation that knows hwo to handle a source that was +A terms implementation that knows how to handle a source that was Interesting how I could fix the weired character w/o seeing the typo. *wonders* created through a contextual source factory. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On 2007-05-21 07:39:57 +0200, Martijn Pieters [EMAIL PROTECTED] said: [...] However, it appears that the switch to eggs requires additional precautions to avoid your python system to be 'polluted' with various Zope3 packages. Perhaps we should recommend using workingenv for development work instead? No. Use buildout. Nothing will be installed into the system Python, everything will be wired correctly. Use buildout. :) -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add flexibility to zope.formlib.form.EditFormBase
On 2007-05-08 08:02:37 +0200, Michael Howitz [EMAIL PROTECTED] said: Am 07.05.2007 um 08:19 schrieb Christian Zagrodnick: You can, but there's a trick to it---call handle_edit_action.success() instead of calling handle_edit_action directly. Right. I used something like this here in a custom form: @zope.formlib.form.action( _(Apply), condition=zope.formlib.form.haveInputWidgets) def handle_edit_action(self, action, data): super(EditForm, self).handle_edit_action.success(data) self.request.response.redirect(self.nextURL()) return Redirect... This looks not nice because you have to redeclare the whole action including translation of the name and the condition. But if nobody agrees to my suggestion of a customizable applyChanges I will have to do it this way. (Although the two solutions do not interfere.) If it makes your life easier change it. I'm not really seeing the point in not chaning it, I was just posting my solution. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add flexibility to zope.formlib.form.EditFormBase
On 2007-05-05 20:07:07 +0200, Marius Gedminas [EMAIL PROTECTED] said: On Fri, May 04, 2007 at 09:26:17AM +0200, Michael Howitz wrote: I'm using zope.formlib.form.EditFormBase and want to normalize data =20 before saving it. Saving is done by the applyChanges function which is called from =20 handle_edit_action. The problem is that handle_edit_action is an action, so I can't =20 easily subclass and do a super call to handle_edit_action. You can, but there's a trick to it---call handle_edit_action.success() instead of calling handle_edit_action directly. Right. I used something like this here in a custom form: @zope.formlib.form.action( _(Apply), condition=zope.formlib.form.haveInputWidgets) def handle_edit_action(self, action, data): super(EditForm, self).handle_edit_action.success(data) self.request.response.redirect(self.nextURL()) return Redirect... -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZPT missing header
On 2007-03-10 08:20:04 +0100, Dieter Maurer [EMAIL PROTECTED] said: Christian Zagrodnick wrote at 2007-3-9 15:07 +0100: ... zope.pagetemplate.pagetemplatefile is removing the header. So it is the pagetemplate, yes. It did so for resources as well. But *only* for the plain HTML header, *not* an XHTML header. I don't see why they should behave different. While I agree that they should behave identical, I do not see a reason to remove the header. Why adding additional complexity, which may introduce bugs (as we have seen)? Right. I just wonder about the intensions to remove it initially. If nobody objects I will remove the stripping of the HTML header (as time allows). -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZPT missing header
Hi On 2007-03-09 13:40:17 +0100, Stephan Richter [EMAIL PROTECTED] said: On Thursday 08 March 2007 21:06, Roger Ineichen wrote: Some test do not pass in our application with the newest Zope3 trunk. Can somebody explain what's happen to the meta header info. In our Page Template the following header get lost: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Roger forgot to mention that this is probably due to this checkin: See checkin 73025 from zagy: - zope.pagetemplate.pagetemplatefile introspects the html http-equiv header to guess the content encoding. This did not work for XHTML content. - zope.app.publisher.browser.pagetemplateresource sets the Content-T ype header like the other page templates do it. This basically fixes page templates in resource directories having a byte order mark. Those were delivered as text/plain. If we do not get an explanation what happens here including a fix, I am goi ng to revert this checkin. The point is, that a header like meta http-equiv=Content-Type content=text/html; charset=UTF-8 i.e. plain old HTML was going away all along. I made it consistent so there is the same behaviour for HTML and XHTML. What the PT resource does is taking the http-equiv header and making a real HTTP header out of it. Frankly I have no idea why it is *removing* the http-equiv then. Maybe because it is redundant. But it would be easy to just keep it. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZPT missing header
On 2007-03-09 14:55:46 +0100, Stephan Richter [EMAIL PROTECTED] said: On Friday 09 March 2007 08:32, Christian Zagrodnick wrote: Frankly I have no idea why it is *removing* the http-equiv then. Maybe because it is redundant. But it would be easy to just keep it. So, is PT removing http-equiv? If this is the behavior in page templates all along and just got fixed for resources, then we will adjust our code. Not exactly. zope.pagetemplate.pagetemplatefile is removing the header. So it is the pagetemplate, yes. It did so for resources as well. But *only* for the plain HTML header, *not* an XHTML header. I don't see why they should behave different. I stumbled upon that when inserting an XHTML file with a BOM. This file was published as text/plain while a HTML file with a BOM was published as text/html. Thanks a lot for the clarification. You are welcome. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3 branch: zope.app.interface.tests.test_interface.PersistentInterfaceTest failing
On 2007-03-07 17:54:35 +0100, Ross Patterson [EMAIL PROTECTED] said: Christian Zagrodnick [EMAIL PROTECTED] writes: Hoi the Zope 3.3 branch tests fail here: Error in test test_persistentDeclarations (zope.app.interface.tests.test_interface.PersistentInterfaceTest) Traceback (most recent call last): File /sw/lib/python2.4/unittest.py, line 260, in run testMethod() File /Users/zagy/development/Zope33/src/zope/app/interface/tests/test_interface.py, line 183, in test_persistentDeclarations barmodule.IBar.dependents.keys()[0]._Provides__args AttributeError: 'PersistentImplements' object has no attribute _Provides__args' That's mine, I just finished taking a look at it. I did fresh checkouts of branches/3.3 and trunk and ran make test on them both just to be safe. I can't reproduce this failure. I'm not really up to speed on the eggs or buildout stuff. I'm just using the SVN bundle at: svn+ssh://[EMAIL PROTECTED]/repos/main/Zope3/branches/3.3 Should I be using something else? No, same URL here. Just did make clean make and rerun. But I keep getting the error. Could this be a Mac issue only? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3 branch: zope.app.interface.tests.test_interface.PersistentInterfaceTest failing
On 2007-03-08 19:36:06 +0100, Ross Patterson [EMAIL PROTECTED] said: Christian Zagrodnick [EMAIL PROTECTED] writes: On 2007-03-07 17:54:35 +0100, Ross Patterson [EMAIL PROTECTED] said: Christian Zagrodnick [EMAIL PROTECTED] writes: Hoi the Zope 3.3 branch tests fail here: Error in test test_persistentDeclarations (zope.app.interface.tests.test_interface.PersistentInterfaceTest) Traceback (most recent call last): File /sw/lib/python2.4/unittest.py, line 260, in run testMethod() File /Users/zagy/development/Zope33/src/zope/app/interface/tests/test_interface.py, line 183, in test_persistentDeclarations barmodule.IBar.dependents.keys()[0]._Provides__args AttributeError: 'PersistentImplements' object has no attribute _Provides__args' That's mine, I just finished taking a look at it. I did fresh checkouts of branches/3.3 and trunk and ran make test on them both just to be safe. I can't reproduce this failure. I'm not really up to speed on the eggs or buildout stuff. I'm just using the SVN bundle at: svn+ssh://[EMAIL PROTECTED]/repos/main/Zope3/branches/3.3 Should I be using something else? No, same URL here. Just did make clean make and rerun. But I keep getting the error. Could this be a Mac issue only? Ah, that's it! Somone committed a fix to a Mac specific issue on trunk but didn't back port it to the 3.3 branch. I got my hands on a MacBook and was able to reproduce the error. I've merged the changes and now the tests pass on said MacBook. Ah. Now they're passing. Thanks Ross. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.3 branch: zope.app.interface.tests.test_interface.PersistentInterfaceTest failing
Hoi the Zope 3.3 branch tests fail here: Error in test test_persistentDeclarations (zope.app.interface.tests.test_interface.PersistentInterfaceTest) Traceback (most recent call last): File /sw/lib/python2.4/unittest.py, line 260, in run testMethod() File /Users/zagy/development/Zope33/src/zope/app/interface/tests/test_interface.py, line 183, in test_persistentDeclarations barmodule.IBar.dependents.keys()[0]._Provides__args AttributeError: 'PersistentImplements' object has no attribute '_Provides__args' -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.2 branch: zope/app/ftests/doctest.txt failing
+ nbsp; + /div + /div + /div + div id=footer / + div id=logger / + /td + /tr + /table + /body + /html + BLANKLINE + BLANKLINE -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
On 2006-12-19 16:12:47 +0100, Martijn Faassen [EMAIL PROTECTED] said: I think only Michael Kerrin actively supports Twisted. I'm not sure what the status of that is. The last time I made time to pay attention to this, at the time we released Zope 3.2, the Twisted WSGI integration had a lot of problems. I tried to address the most urgent ones, but ended up with a server that was much slower than ZServer, which was much slower than the Zope 2 server. I was also alarmed that we were maintaining our own Twisted WSGI integration. I don't know if the Twisted community has gotten behind WSGI. If not, I'm not sure we gained anything from using Twisted. I'm having second thoughts about the Twisted integration for a number of reasons: * Twisted people actively dislike eggs. They won't eggify Twisted any time soon. *gaah* * Twisted async approach doesn't really match Zope's threaded approach. I'm not sure how the twisted integration works at all. But combining both worlds in a way seems good. Twisted's callLater would be very handy for instance. The zc.async package allows some support for asynchronous calls. All that would be gone w/o using twisted. and your reason: * Who is maintaining Twisted's WSGI integration? If that's us, then that sucks. That's true. Especially because the Zope people think differntly than Twisted people ;) -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
