RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Philipp [...] > I'll be fine with creating new directives instead of changing > the old ones, if that's what the majority prefers. But then > I'd very much like to see a Death Certificate for the old > directives made out for some time in the future (doesn't have > to be 2 releases, could be more). I don't like the proposal and the direction where you are Going, but this is another part. But I'm fine with this changes as long as the browser:page directive doesn't change in any way. Regards Roger Ineichen > Philipp > > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: RFC: The browser:page compromise
Hi Philipp > > That confuses me even more. I *am* proposing changes to the > > browser:page directive... > > Hmm, never mind. I think I understand what you mean. You'd > like to see new directives, instead of changing the old ones. Right? Yes, I think it's very important to bring a little stability to the Zope3 framework rather then change every release such fundamental parts like directives. Regards Roger Ineichen _______ 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: RFC: The browser:page compromise
Hi Tonico > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tonico Strasser > Sent: Friday, April 21, 2006 2:10 AM > To: zope3-dev@zope.org > Subject: [Zope3-dev] Re: RFC: The browser:page compromise > > Philipp von Weitershausen schrieb: > > I also think it makes it hard to understand. In response to this > > proposal, several people have asked me "By the way, what's the > > difference between and > anyhoo?" That > > alone has proven my point that the current system makes it > absolutely > > incomprehensible of what's going on behind the scenes. > > The name "browser" for a namespace sux IMHO ;) The idea of a namspace called browser is the following: We use the namespace browser for *presentations* (the earlier name for pages) which depends on the IBrowserRequest. This is also reflected in the package structure like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. > How is a browser defined in Zope 3 and how are these names > related to it? > > addMenuItem > addform > containerViews > defaultSkin > defaultView > editform > form > i18n-resource > icon > layer > menu > menuItem > menuItems > page > pages > resource > resourceDirectory > schemadisplay > skin > subMenuItem > subeditform > tool > view > viewlet > viewletManager All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. The exception zope:view doesn't use a implicit request this is the reason why the zope:view is also existent next to the browser:view. This means the zope:view directive can be used together with a different request then IBrowserRequest. > What is a page? Is a dynamic stylesheet or a dynamic > javascript or an Atom feed a page? Does a page provide a > mime_type? Should a page do content negotiation? More or less all of this is a adapter called on a context and request providing a interface and a optional name producing a response ;-) Remember page is a replacement for the earlier name *presentation" which was a little bit a to long naming. > Create a new clean namespace and call it user_interface (or ui)! :) I think a name like ui doesn't reflect the request type and will be a bad idea for register *presentations* for json which are registred like right now. But if you like to use etc, you can do this by simply setting the namspace to: xmlns:ui="http://namespaces.zope.org/browser"; And then use btw, I whould like to use only one directive called *zope* for all directives. The directive *browser* is not really needed except for let us use zope:view and browser:view ;-) Regards Roger Ineichen > Tonico > > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ 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: RFC: The browser:page compromise
Hi Tonico > At some point it will be necessary to make the framework > understandable for "normal" UI designers or we'll stick with > ugly user interfaces forever :) I think it's pretty clear right now. Do you really think if soembody don't understand what a folder json or browser should contain he ever will be able to understand what he has to do in ZCML? (I guess this is really not a naming problem) Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? > >> How is a browser defined in Zope 3 and how are these names > related to > >> it? > > [...] > > > All of this directive are based on the IBrowserRequest. > > Other requests like FTPRequest don't have a menu layer etc. > > How is a BrowserRequest different from a HTTPRequest? A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. The browser request is based on the http request which does the base stuff like cookie handling etc. Regards Roger Ineichen > Tonico > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ 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: RFC: The browser:page compromise
Hi Tonico > I once tried to understand how the default skin works -- > after that I gave up the idea of creating a new ZMI skin > myself. (Especially the MacroMagic was difficult to > understand, but I want to try again someday). I see, I personaly like macros, but it is true, sometimes it is very hard to fit the pices to a big picture. Perhaps it whould help if we have another directive ;-) called which whould handle the macro registration rather then use . This whould let us use some concept of a explicit *philiKON* factory for macro registrations which makes the standard_macros mapping a little more transparent. What I really dislike on the browser:page registration for macros, is, that such macros are also callable as traversable views rigth now. I whould like to see a different lookup for macros in the future. This could look like: Macro lookup right now: what I like to see is something like: Such a macro could be lookuped by a ITALESExpression called *macro* similar to the IContentProvider implementation. The *StandardMacros* could be a mapping registred as a python factory. The *StandardMacros/page* knows how to lookup a registred macro called *page* in the *StandardMacros*. See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMac roRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? > I like Philipps proposal because it tries to remove some of > that magic that makes it often difficult to understand (or to > accept) the concept. > > > Do yo have a simpler naming and/or module/package structure > concept in > > mind? If so, is this not only a part of a project or > application like > > a CMS etc? Do you think UI Developers should work out of > the box with > > a Zope3 instance? > > Not at the moment. > > > A browser request offers a API for collecting browser (client) > > releated informations like charset settings. This is done via the > > interface IUserPreferredCharsets. > > Interesting, does it also offer an API for preferred language > and preferred media? There is a adapter providing the interface IUserPreferredLanguages which can be used on requests. This adapter reads the request value *HTTP_ACCEPT_LANGUAGE* in the method *getPreferredLanguages*. The adapter is registred for the IHTTPRequest. > > A browser request also deals with form data and collects the given > > form input into a FieldStorage object. The most important > part here is > > that a browser request knows how to handle file upload. > > Interesting. > > > The browser request is based on the http request which does > the base > > stuff like cookie handling etc. > > Thanks for explanation. no problem Regards Roger Ineichen > Tonico > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: RFC: The browser:page compromise
Hi Philipp > -Original Message- > From: Philipp von Weitershausen [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 22, 2006 9:15 AM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org > Subject: Re: RFC: The browser:page compromise > > [EMAIL PROTECTED] wrote: > >>> That confuses me even more. I *am* proposing changes to the > >>> browser:page directive... > >> Hmm, never mind. I think I understand what you mean. You'd like to > >> see new directives, instead of changing the old ones. Right? > > > > Yes, I think it's very important to bring a little stability to the > > Zope3 framework rather then change every release such fundamental > > parts like directives. > > I will accept this criticism when you tell Jim that his work > on jim-adapter branch was wrong for that same reason and when > you tell me (which you haven't) that my work on > MakeZopeAppSmaller is also wrong for that reason. That's a difference. Jim's *adapter* refactoring will bring us a speed up and solves some problems in the adapter registry implementation. (lookup multiadapter by it's registration tuple). Your proposal is just a *cosmetic* change which forces us to change existing projects and like Florent says: We have to write additional python classes for just that. I don't buy this as really usefull. > Sorry, I just don't buy it. We're still refactoring some key > packages like zope.component and you're trying to shoot down > a refactoring of 3 ZCML directives? Yes, Why the hell do I have to write additional python classes for each page registration after your refactoring? I don't by this as a improvment. If we do this, I can add the browser:page directive back as a high level directive and then the need for write additional python classes is just a YAGNY like before. Is this really a improvment? Another problem is, that we have mor then 6 projects build with zope3 up and running. Such a improvment is not nice and will force us to change more then ~300 existing page registrations. It's a horror to think about how many python class we have to write if we do this simplification!!! You totaly ignore that Zope3 is not a experimental framework now and stability is also a criteria which should recognized. Please recognize that some people have built applications with zope3 since more then 2 years now. And respect that they are not willing to just change everything wich forces them to go other ways then before without a real *improvment*. btw, I don't dislike the refactoring at all, but I just dislike that we have to update our projects for *this* simplification. We have at least to provide both way of registration. Perhaps it's really time to add a higher level directive pool for such refactorings. Is this a option for you? Regards Roger Ineichen > Philipp > > ___ 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: RFC: The browser:page compromise
Hi Philipp > ZCML as of Zope 3.2 is inconsistent and to someone who's new > and doesn't know every little detail from behind the scenes > it's very obscure. And then it also makes debugging hard > which has bitten me personally quite a few times. I explained > this is a reply to Rocky Burt in this thread: > http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html I don't telling that you are not right at all ;-) It's just not correct to remove the old way of doing. > Now, would you rather make an attempt to document the > inconsistent (and hard to maintain, not to forget!), or > wouldn't you rather make an attempt at fixing the damn thing? I guess, making the refactoring and support a high level directive doing the old way will solve the problem. Regards Roger Ineichen > Philipp > > _______ 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: RFC: The browser:page compromise
Hi Philipp > > See also my (a little old) proposal at: > > > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Simpl > > ifyMacroRegistration > > > > Note: the proposal is a little bit old and I whould change the > > directive browser:macros and make explicit use of a python factory > > rather then use a implicit mixin class. > > > > What do you think Philipp? > > This isn't part of the discussion about this proposal. > > Just to be clear: > > * Having to register macros as pages when they're not meant > to be publishable sucks. > > * @@standard_macros sucks a bit too (too much indirection). > It sure confuses people (like Tonico, as he says himself). > > * I'd rather not invent a new ZCML directive nor a new TALES > expression type (I don't like this about viewlets and > contentproviders). > > I could imagine a new traversal namespace: > > > Here, 'page' is an adapter from (context, request) (it's a > view) to IMacro or something. It will also be registered as > such (as a or just an ). > > I think viewlets and contentproviders should have taken the > same road and used traversal namespaces. That's what they're for :). I don't think so. ITALESExpression are built for this use case. My context doesn't need to have a ++macro++ namespace! My context doesn't know about macros and viewlets. Macros or viewlets depend on context and request. This is the reason why we implemented a lookup via tales expression and not a traversal namespace on our context. > If we shall discuss this any further, I suggest we move into > a separate thread. Yup > Philipp > ___ 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: RFC: The browser:page compromise
Hi Philipp > > IMO it would be great to solve this properly, because one point of > > using views is to have a fine control over what to publish > and what not. > > And this is a bit broken at this point, currently. > > Right, that's why page templates that just provide macros > should be registered unpublishable browser views and not > browser pages. > > You see how far into the confusion the > directive has brought us? Yes, but this is only a problem how we lookup views/pages via /@@ in templates. The implementation of a *provider* tales expression for viewlet manager totaly avoids this :-) Regards Roger Ineichen > Philipp > ___________ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ 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: Re: RFC: The browser:page compromise
Hi Balazs > Hi Roger, > > On Sat, 22 Apr 2006 01:56:46 +0200, dev wrote: > > What I really dislike > > on the browser:page registration for macros, is, that such > macros are > > also callable as traversable views rigth now. I whould like > to see a > > different lookup for macros in the future. > > That was one of my first annoyances, when arriving as a total > newcomer to the world of Z3. After asking a few of the smart > guys, who said it is not possible to set this the way I > wanted, I came up with a workaround of using a view class > that overwrites __call__ and throws an exception from it. I'm > using this since then but I don't like workarounds (not that > it'd be such a bad one). > > IMO it would be great to solve this properly, because one > point of using views is to have a fine control over what to > publish and what not. > And this is a bit broken at this point, currently. I see, I hope to find time and discuss this with Pilipp and others and find a way to implement a simpler/explicit macro handling. Probably we really need to start implementing a higher level set of directives which do more then the simplyfied one's. Regards Roger Ineichen _ END OF MESSAGE > -- > Balazs Ree > > > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Formlib error handling
The formlib.EditForm dosen't catch all errors form widgets.
The following method catches only InputError:
def getWidgetsData(widgets, form_prefix, data):
errors = []
form_prefix += '.'
for input, widget in widgets.__iter_input_and_widget__():
if input and IInputWidget.providedBy(widget):
name = _widgetKey(widget, form_prefix)
if not widget.hasInput():
raise interfaces.FormError("No input", name)
try:
data[name] = widget.getInputValue()
except InputErrors, error:
errors.append(error)
return errors
How can I enhance the error handling for
WrongContainedType or NotUnique which are ValueErrors?
Do I miss something or is it correct to improve the
validation in this method. Or is there in general a mess
in the widget implementation and it's error handling.
Hm, is it correct how the sequence widget handles errors
in the getInputValue method?
e.g.
def getInputValue(self):
"""Return converted and validated widget data.
If there is no user input and the field is required, then a
``MissingInputError`` will be raised.
If there is no user input and the field is not required, then
the field default value will be returned.
A ``WidgetInputError`` is raised in the case of one or more
errors encountered, inputting, converting, or validating the data.
"""
if self.hasInput():
self.preserve_widgets = True
sequence = self._type(self._generateSequence())
if sequence != self.context.missing_value:
self.context.validate(sequence)
elif self.context.required:
raise MissingInputError(self.context.__name__,
self.context.title)
return sequence
raise MissingInputError(self.context.__name__, self.context.title)
and dosen't convert errors raised in
*self.context.validate(sequence)* to a ValidationError (InputErrors) ?
Regards
Roger Ineichen
_
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 Hünenberg
phone +41 (0)41 781 01 78
mobile+41 (0)79 340 52 32
fax +41 (0)41 781 00 78
email [EMAIL PROTECTED]
_
END OF MESSAGE
___
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: RFC: The browser:page compromise
Hi Philipp > > Yes, > > but this is only a problem how we lookup views/pages via /@@ in > > templates. > > That's how we lookup views. @@ is short for ++view++. > Traversal namespaces are the way to lookup things that are > not direct attributes. The namespace ++view++ is in the first line a namespace which makes it possible to use the same naming for ojects and views on a container. Second this is callable via the @@ in page templates. The implementation that we didn't use a tales expression is bad. It doesn't make sense to me that we can automaticly use traversal namespace in tales. I think the API for implement additional functionality is the ITALESExpression interface. Every other implementation which makes something possible in TAL is bad. That's just what I think. > > The implementation of a *provider* > > tales expression for viewlet manager totaly avoids this :-) > > As I said in another post, I think tales expressions are abused there. > For looking up views, would you not use ++view++ but rather a view: > TALES expression? Or for resources? I think not. > > Getting from an object to a view (=view,page,viewlet,etc.) of > this object is traversal. It belongs into a traversal adapter. Yes, I know, but where doe we describe the interface for that? Is there a interface somewhere that I can see why I can call traversal namespace from TAL? Perhaps I missed this till now. How do you explain the TAL implementation of a @@ lookup to someone? Regards Roger Ineichen > Philipp > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Windows Binaries
Hi Tim > Subject: Re: [Zope3-dev] Windows Binaries [...] > Nope. I used to build Zope3 routinely on Windows, and all I > did was open WinZip and tell it to recursively suck up all > the .pyd files. > Nothing automated, because it was faster to do it by hand. > I'm still happy to do that when someone emails me saying it's > needed [...] Cool thanks, that's fine for me. Regards Roger Ineichen ___________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] LocationProxy refactoring
Hi Jim, The method _verify in zope.interface.verify raises the exception for decorated LocationProxy methods at line 75. else: if not callable(attr): raise BrokenMethodImplementation(name, "Not a method") # sigh, it's callable, but we don't know how to intrspect it, so # we have to give it a pass. continue Is it possible to change it to: else: if not (callable(attr) or type(property)): raise BrokenMethodImplementation(name, "Not a method") # sigh, it's callable, but we don't know how to intrspect it, so # we have to give it a pass. continue which will allow to use the decorator "@non_overridable" for methods on proxies like: @non_overridable def has_key(self, key): return getProxiedObject(self).has_key(key) Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE _______ 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: Zope 3 lacks Ajax capability?
Hi all, There is such a thing in z3! Or at least in the "new" zope3.org implemnetation ;-) I remember that Uwe Oestermeier was developing something like a livepage which can receive and send streams of HTML on a open request. See this for more information, but don't ask me if it's working. http://svn.zope.org/zope3org/trunk/src/zorg/live/README.txt?rev=66712&view=m arkup Please contact Uwe Oestermeier if you have questions. I guess you can find his address somewhere at the sprint announcment list. He was organizing the Isar Sprint. Hope that's usefull. Regards Roger Ineichen _ END OF MESSAGE > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Zachery Bir > Sent: Monday, May 15, 2006 7:53 PM > To: Jeff Rush > Cc: zope3-dev@zope.org > Subject: Re: [Zope3-dev] Re: Zope 3 lacks Ajax capability? > > On May 15, 2006, at 1:49 PM, Jeff Rush wrote: > > > Benji York wrote: > >> Zachery Bir wrote: > >>> I think Benji's commenting on the fact that you're creating a > >>> synchronous connection when you hold it open like that. > >> Exactly. As Jean-Marc noted, Jeff's talking more about > "streaming" > >> than "asynchronicity" (is that a word?). > > > > Well the connection itself is synchronous but that data > flowing over > > it is async in that the server can send something to the > > client at any time w/o regard to the usual REQUEST/RESPONSE > cycle. > > I guess I didn't think of it as streaming because I wasn't > sending a > > large quantity of data over the connection, just many small chunks > > representing Javascript fragments to be invoked within the client. > > > >>> FWIW, I've been using MochiKit's Async package for writing Zope > >>> 3 apps with AJAX. > >> MochiKit is one of life's little joys. > >> (And I'm not being sarcastic, ask hard to believe as that is.) > > > > I looked at MochiKit and studied the Async package, but perhaps I > > didn't understand it. I only saw ways for the client to sneak HTTP > > REQUESTSs to the server behind the user's back, but nothing for the > > server to reach out and shove something into the client > whenever the > > server, not the client, decided it was time. I'd rather > not have the > > client polling the server for said data with HTTP REQUESTs. > > Depends entirely on your application, I guess. Comet (the live > connection) doesn't scale particularly well. It suits some > applications quite nicely (e.g. small number of users). For > other purposes, it's wholly unsuited. But that's not an > indictment of Zope 3's ability to deploy AJAX applications. > Perhaps Comet apps, but not AJAX. > > Zac > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] BBB
Hi Adam > Behalf Of Adam Groszer > Sent: Tuesday, May 16, 2006 8:32 AM > To: zope3-dev > Subject: [Zope3-dev] BBB > > Hi there, > > I'm working on removing BBB warnings of our current app for 3.3. > For the directive it was possible to give the > factory some parameters like this: > >name="doctype" > factory="..vocab.ContainerVocabulary" > containerName="doctype" /> > > Now, with the directive that's not possible. Write a own factory like: class DocTypeContainerVocabulary(ContainerVocabulary): def __init__(self): super(DocTypeContainerVocabulary, self).__init__() self.containerName = 'doctype' and also you have to *patch* your class with : classProvides(DocTypeContainerVocabulary, IVocabularyFactory) then use the factory like: It's simple isn't it? the *good* thing is if you use this vocabulary for twenty vocabularies, you have to do this for each of them. This is realy ugly, but simple. Regards Roger Ineichen _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formlib error handling
Hi Gary, > -Original Message- > From: Gary Poster [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 17, 2006 7:36 PM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org > Subject: Re: [Zope3-dev] Formlib error handling > > > On Apr 22, 2006, at 11:31 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > wrote: > > > The formlib.EditForm dosen't catch all errors form widgets. > ... > > Hey Roger. Your email has been sitting open on my computer > for weeks, reminding me to reply, and I want to get rid of > it. :-) Did you put a collector issue in for this, or was it > resolved in some other way? I solve the problem and added some bugfix, see the different commit messages below. I think the error handling is pretty Ok in the formlib now. Feel free to ask if somthing is unclear. I'm pretty sure that we very extensivly used the formlib in our project. Most improvments depend on useing the formlib with subforms where we setup in the update method. Some implementation use also the zc.table implementation. What I like to implement, is a generic "sub form setup" method which should make it easier to setup sub-forms. Log message for revision 68157: - Improve error handling in formlib: Fix invariant error handling in formlib. The exception Invalid raised in interface invariants where end in a component lookup error because this exception didn't get converted to a usefull error message. Now the error_views method in formlib can handle strings and i18n Message based Invalid exceptions. - Added test for Invalid exceptions handling - Added also a small fix which makes sure that existing errors from master/subforms don't get overriden by calling update in FormBase. - Added note in Changes.txt Changed: U Zope3/trunk/doc/CHANGES.txt U Zope3/trunk/src/zope/formlib/form.py U Zope3/trunk/src/zope/formlib/tests.py Log message for revision 67282: Fix error handling Widget have to raise WidgetInputError and not ValidationError directly. Improve sequence input widget base class methods getInputValue. This will ensure that sequence widgets will set the raised error to the _error attribute before the error get raised. Changed: U Zope3/trunk/src/zope/app/form/browser/sequencewidget.py U Zope3/trunk/src/zope/app/form/browser/tests/test_sequencewidget.py Log message for revision 67279: And added missing import Changed: U Zope3/trunk/src/zope/formlib/form.py Log message for revision 67278: Fix error handling, please double check this! The formlib.form.EditForm doesn't handle ValidationError in the method error_views. I converted ValidationError to WidgetInputError in the method getWidgetsData which is responsible to catch errors raised by the widget getInputValue method. Changed: U Zope3/trunk/src/zope/formlib/form.py Regards Roger Ineichen _________ END OF MESSAGE > Thanks > > Gary > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formlib error handling
Hi Gary [...] > With your change, if the error is (or extends!) Invalid, it > is hardcoded to assume the first argument is a string, > message, or something with a reasonably __str__, translate if > it is a message, and wrap the result with a . I'd much > prefer it if that code were ripped out of error_views and > made, simply, into a view for (Invalid, IBrowserRequest), > perhaps even registered by the formlib zcml. Do you see any > issue with that? No, that's a good idea. btw, I can also live without the additional span tag arround the message string. Do you have time to change this? > Also, I don't love the 'widget_title' stuff in error_views: that > seems to me to be the responsibility of the error view.Is that > new? What's the rationale? No, this was a existing part. I agree, we sould move this part to the error view, if possible. > > Log message for revision 67278: > > Fix error handling, please double check this! > > > > The formlib.form.EditForm doesn't handle ValidationError in the > > method error_views. > > I converted ValidationError to WidgetInputError in the method > > getWidgetsData which is responsible to catch errors raised by > > the widget getInputValue method. > > This is the place in the code that knows the widget name and > label, so it's not unreasonable. What do you mean by this? Is it correct how I converted ValidationError to useable widget input errors? Regards Roger Ineichen > Thanks > > Gary > ___ 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: BBB
Hi Philipp [...] > > [EMAIL PROTECTED] wrote: > >> I'm working on removing BBB warnings of our current app for 3.3. > >> For the directive it was possible to give the factory > >> some parameters like this: > >> > >> >> name="doctype" > >> factory="..vocab.ContainerVocabulary" > >> containerName="doctype" /> > >> > >> Now, with the directive that's not possible. > > > > Write a own factory like: > > > > class DocTypeContainerVocabulary(ContainerVocabulary): > > > > def __init__(self): > > super(DocTypeContainerVocabulary, self).__init__() > > self.containerName = 'doctype' > > > > and also you have to *patch* your class with : > > > > classProvides(DocTypeContainerVocabulary, IVocabularyFactory) > > This is unnecessarily complicated. Simply do: > > class DocTypeContainerVocabulary(ContainerVocabulary): > containerName = 'doctype' > zope.interface.classProvides(IVocabularyFactory) right, that's simpler than my sample. > Btw, the "classProvides" thing isn't "patching". Not sure > what you mean, Roger, but it looks like you wanted to give > this a negative connotation. Ok, sorry that wasn't the target of the word *patching*. But sure I'm not really happy with the additional python code where we have to write and it smells to me like a monky patch pattern if use classProvides outside of the class definition. Your example is much better in this part. Regards Roger Ineichen ___ 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: TALES PathExpr doesn't call old style classes
Hi Philipp, Florent [...] > >> In particular, I'm looking for comments on problem #2. > > > > Well, following the mantra of "explicit is better than > implicit" I'd > > rather have ZPT never call things magically, but I know > that's not the > > problem at hand and it poses backward compat problems anyway... Too > > bad though. I don't agree if I understand this correct. We have attributes or methods which we access from a page template via TAL. right? I don't think we can speak about implicit or explicit. The problem is, that we have one accessor method and two different accessible implementations. If I access a foo() method from TAL it is not implicit if I don't call them, it's more a wrong concept for accessing a method. I whould preferre if both use case get handled by default correct, doesn't matter if I access a attribute or a method. Why not use the proposed PEP3000? And also additional nocall: and call: accessor in a page template. This means existing implementation will not break and everybody how likes to use explicit accessors like call: or nocall: can use it explicit. I think this whould make everybody happy. Or not? I think the nocall: method in TAL is only useful if we like to get a function pointer where we call different times in the template. Or did I miss something? Are there really usecases where something can go wrong if we use the proposed PEP? Regards Roger Ineichen ___ 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: TALES PathExpr doesn't call old style classes
Hi Philipp [...] > > Are there really usecases where something can go wrong if > we use the > > proposed PEP? > > Calling something that may or may not be callable can yield > at least two different exceptions: TypeError or > AttributeError (on __call__). That means we'd already have to > catch two pretty common exceptions and therefore "eat" > exceptions that might occur inside the called routine. [...] You are right, I missed that. Regards Roger Ineichen > Philipp > ___________ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ 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: TALES PathExpr doesn't call old style classes
Hi Philipp, Florent [...] > > There *is* a way to check whether the error resulted from > the current > > frame or a lower frame. Introspections like these have the > tendency to > > be or become hacks, but then again, we use frame > inspections in other > > places, too. > > Yes, I was about to suggest using the standard PJE trick used > elsewhere in Zope 3 (to check for deep ImportErrors), namely: > > try: >ob() > except (TypeError, AttributeError): >if sys.exce_info()[2].tb_next is not None: > raise ># here we know the exception was not "deep" ># so the object isn't callable Good point Regards Roger Ineichen > Florent ___ 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: [Checkins] SVN: Zope3/trunk/src/zope/formlib/Bugfix zope.formlib
Hi Gary [...] > On May 25, 2006, at 12:17 PM, Roger Ineichen wrote: > ... > > Looks good to me for 3.3 also. Ok, the bugfix is merged to the trunk. > > +Note that a EditForm can't make use of a get_rendered method. The > > get_rendered > > +method does only set initial values. > > This sentence got me closer to understanding what you want, at least. I guess we have to think about this concept another time. Perhaps it make sense to add a setRenderedValue concept to the formlib. This well know field method could also make sense at a form level and offer a post process hook for set values on initialized widgets. This could be useful for convert form.request values before they get collected by the field getInputValue method. Regards Roger Ineichen _ END OF MESSAGE > Thanks > > Gary > ___________ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] image libraries implementation in zope3 ?
Hi Gael, Bernd Bernd and I added the z3c repository as a kind of Zope3 community repository at the last swiss easter sprint. I guess your package is a good thing to have it there. We do not have any restriction for packages which are located in this repository, except that they should follow the ZSCP standard which defines only quality aspects. I'm interessted to put it to this location if you like. Bernd What do you think? Did you allready implement such a package for your projects. Regards Roger Ineichen _ END OF MESSAGE > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of gawel > Sent: Friday, May 26, 2006 3:22 PM > To: zope3-dev@zope.org > Subject: [Zope3-dev] image libraries implementation in zope3 ? > > Hi zope3 coders, > > image transformation is a common task for web developpers. > i've created a package to make them stop reinventing the > wheel each time they need to resize an image or something else. > > this package provides an IImageTransformer adapter to adapt an IImage. > IImageTransformer use a named IImageLibrary utility to > transform the image. > i've already implemented an ImagingLibrary for PIL and an > ImageMagickLibrary for ImageMagick but you can implements, > register and then use your own IImageLibrary. > the default IImageLibrary used by IImageTransformer is > configured via zcml. > this way you don't have to take care which library is used > when you resize/rotate your image. > > i'd realy like to see this in the zope3 core or at least in a > z3c/zf package. > my package is named imagelib and is located in lib/python actualy. > i'm sure my code isn't perfect but it's a good starting point > for you guys to implement this. > > i don't have write access to the zope repository so if you're > interested in this package, i will send it to someone with > write access. > > i join my doc test file to this email. > > regards, > > -- > Gael > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] image libraries implementation in zope3 ?
Hi Benji [...] > gawel wrote: > > image transformation is a common task for web developpers. > > i've created a package to make them stop reinventing the wheel each > > time they need to resize an image or something else. > > -0, I don't quite see the need to abstract away image > manipulation libraries. Could be useful but we can't have it in the Zope3 core because of it's dependency to PIL and ImageMagick. I guess the right thing is to put it in a additional repos like z3c. Regards Roger Ineichen _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] What's wrong with my configure.zcml?
Hi Florian
Change the default defined in the interface for the
layer attribute to:
default=u'',
instead of:
default='',
I guess there is a layer attribute somewhere
in a interface which looks something like:
layer = zope.schema.TextLine(
title=_('Layer'),
default=u'',
)
Or not?
Regards
Roger Ineichen
_
END OF MESSAGE
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Florian Lindner
> Sent: Sunday, June 04, 2006 12:25 PM
> To: zope3-dev@zope.org
> Subject: [Zope3-dev] What's wrong with my configure.zcml?
>
> Hello,
> sorry for the post to the dev list but on the users list no
> one was able to help me and I got no idea what I can try
> My Zope3 (most recent SVN version gives that error on startup):
>
> [...]
> File
> "/home/florian/Zope3/src/zope/schema/_bootstrapfields.py",
> line 263, in _validate
> super(MinMaxLen, self)._validate(value)
> File
> "/home/florian/Zope3/src/zope/schema/_bootstrapfields.py",
> line 165, in _validate
> raise WrongType(value, self._type)
> zope.configuration.xmlconfig.ZopeXMLConfigurationError:
> File "/home/florian/Desktop/zope/etc/site.zcml", line 7.2-7.55
> ZopeXMLConfigurationError:
> File
> "/home/florian/Desktop/zope/etc/package-includes/xgm-configure.zcml",
> line 1.0-1.25
> ZopeXMLConfigurationError:
> File "/home/florian/Desktop/zope/lib/python/xgm/configure.zcml", line
> 2.4-2.34
> ZopeXMLConfigurationError:
> File
> "/home/florian/Desktop/zope/lib/python/xgm/browser/configure.z
> cml", line
> 2.4-2.31
> ZopeXMLConfigurationError:
> File
> "/home/florian/Desktop/zope/lib/python/xgm/browser/skin/config
> ure.zcml",
> line 3.4-7.6
> ConfigurationError: ('Invalid value for', 'layer', "('',
> )")
>
>
> I have attached xgm/browser/skin/configure.zcml. It is not
> containing any unicode nor does interface.py (in which is the
> layer declared).
>
> [EMAIL PROTECTED] ~/Desktop/zope/lib/python $ file
> xgm/browser/skin/configure.zcml
> xgm/browser/skin/configure.zcml: ASCII text [EMAIL PROTECTED]
> ~/Desktop/zope/lib/python $ file xgm/interfaces.py
> xgm/interfaces.py: ASCII Java program text, with CRLF line terminators
>
> (don't know why file thinks it's java...)
>
> Any one got any idea what I can do?
>
> Thanks,
>
> Florian
>
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] invoking method in skins
Hi Roy [...] > > Folks, > > I have two skins - A and B, where B extends A. Both A and B > have the same named attribute "methodOne". I guess you mean view "methodOne" and not attribute which is registred as a page or view in ZCML. right? > I find that from within another method template > (/++skin++B/obj/@@methodFive), if I invoke "view/methodOne", > the method invoked is /++skin++A/obj/@@methodOne, not skin > B's. Is there a way to get to B's methodOne? Try this: /++skin++B/path/to/obj/@@methodOne probably it's not a good idea becaues you need to apply the skin after the site root. I think it's not a good Idea to call views from a different skin in another skin. Or are you looking for a skin switcher? There is a method called applySkin which will switch a skin If you really need to do this, you can switch the skin call the method and switch the skin back in a python method registred as a view. I recommend to register the two different methods under different names if you don't use a "skin switcher". Regards Roger Ineichen _____ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Hi Philipp good idea, just some update what allready happen when you where in China ;-) [...] > I see a few packages lurking in svn.zope.org that I can't > make much sense of: > > * For example, what is zope.generic? I can't find a > README.txt anywhere in the top-level directories. What I > *can* see is that it seems to be another big bag for > subpackages like zope.app. I thought we were getting rid of > those? I'm also wondering why it carries the 'zope' top-level > namespaces. Judging from the checkins, it seems to be a > Dominik + Roger project. Last but not least there's the name > "generic" that I can't make much sense of... If you take a closer look at this package and you will see that each subpackage is well documented. The generic package collection is/was developed/mentained by Dominik. The zope.generic sub-package are very well layered and have clear dependency that's the reason why they are containd in a collection package. I'm not fimilar with the state of the 'generic' project right now. But it's a really cool concept. > * For example, what does the 'z3c' namespace package stand > for? Who's behind this stuff? And why does it sometimes use > 'sandbox' or 'Sandbox' > instead of or in parallel of 'trunk' for its main development branch? The z3c top level package is a namespace for additional packages where I and Bernd started to use at the SwissEasterSprint. We like to provide usefull implementations there, which are useable for Zope3. The packages in the z3c namespace should follow the ZSCP proposal that's the reason why we started to use the zope repository. Please take also a closer look at the ZSCP concept where we implemented based on Stephans work at the sprint http://svn.zope.org/zf.zscp/ btw, this application is ready to use, perhaps it needs some adapter refactoring migration work. > * For example, is ldapauth still maintained? Is it > bitrotting? Can it go away? > > > So, there you have typical cases of three problems I > currently see with stuff in svn.zope.org: > > * Uncontrolled package proliferation w/o consistent naming > > * Inconsistent use of subversion conventions > > * Undocumented packages (no package metadata available) > > > Basically, what I'm really asking is: > > - Do other people also think it'd be a good idea to come up > with some repository guidelines? Stephan had a proposal about > specifying package metadata and code maturity/quality, I > think it's worth working towards easily accessible info like > that. If others agree, then let's get started. Not started, just make progress in what allready started with Stephans proposal and the ZSCP implementation ;-) Yes, I agree Perhaps you can check the proposal and see what we did in http://svn.zope.org/zf.zscp/. I guess there is more to implement but right now it's working and very professional looking. Thanks to Kamal Gill for the great desing work! > - Should this be part of the Zope Foundation development > process (which again seems to be worked out by the Zope > Management Organization)? If so, I'll hereby volunteer to > join such a committee and contribute my ideas (especially on > package organization in the repository and the associated > development process). I really hope that we adapt the prosess described in Stephans ZSCP proposal. http://svn.zope.org/zf.zscp/trunk/src/zf/zscp/ProcessAndRepository.txt?rev=6 6671&view=markup Whould be cool if we could make progress on what Stephan started with the proposal and your ideas. Regards Roger Ineichen > Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Hi Philipp, Dominik Dominik, can you give a short overview what zope.generic can do? [...] > > If you take a closer look at this package and you will see > that each > > subpackage is well documented. > > Right. But that information isn't easily accessible. You have > to go to zope.generic/trunk/src/zope/generic/foobar. That's > FIVE directory layers down from zope.generic! Yes, that's true, but if you install only one package from the 'zope.generic' collection you need to have that README.txt in this package and not more then that. > Another question I raise: Why are there subpackages in the > first place? > And what's the rationale for calling it 'generic'. It's be > like calling it 'zope.fast' or 'zope.easy': you get no idea > about the contents of the package. Of course, I know why it's > called 'zope.generic'. Because it's a package *collection*. I > think package collections (e.g. like zope.app or > zope.products which we used to have some years ago) are a mistake... I'm not sure if that is also right for the generic package. The generic package is ONE concept which is implemented in different reusable sub-packages which also can be used as single packages for just one aspect of the generic concept. > > The generic package collection is/was developed/mentained > by Dominik. > > The zope.generic sub-package are very well layered and have clear > > dependency that's the reason why they are containd in a collection > > package. I'm not fimilar with the state of the 'generic' > project right > > now. But it's a really cool concept. > > I'm not convinced that easily :). Perhaps sketching out what > it really is and what its purpose is would help. I think Dominik can explain the generic pattern. All I can say this quickly, you can define new instances only based on schemas without a class implementation. It's a kind of ZClasses, Archetypes in a clean Zope3 like implementation. Generic means you can define generic components which are initializable and configurable during the runtime. There is also a pattern for enhance such a generic instances via plugins. All I can say, it's generic ;-) > >> * For example, what does the 'z3c' namespace package stand > for? Who's > >> behind this stuff? And why does it sometimes use 'sandbox' or > >> 'Sandbox' > >> instead of or in parallel of 'trunk' for its main > development branch? > > > > The z3c top level package is a namespace for additional > packages where > > I and Bernd started to use at the SwissEasterSprint. > > Great. This should be written down somewhere. (I'm not > blaming you for not having done this; we have no rule for > this right now. I think we should have a rule, though). no problem, I agree to have a place for such infos. The README.txt files are not good enough for give a overview because you have to checkout first or browse the really slow repos with a browser. Tell me where is somewhere and I can write something ;-) > >> - Do other people also think it'd be a good idea to come > up with some > >> repository guidelines? Stephan had a proposal about specifying > >> package metadata and code maturity/quality, I think it's worth > >> working towards easily accessible info like that. If others agree, > >> then let's get started. > > > > Not started, just make progress in what allready started > with Stephans > > proposal and the ZSCP implementation ;-) > > > > Yes, I agree > > Perhaps you can check the proposal and see what we did in > > http://svn.zope.org/zf.zscp/. I guess there is more to > implement but > > right now it's working and very professional looking. > > Thanks to Kamal Gill for the great desing work! > > I'm not as much looking for a website that gathers all the > ZSCP information as much as for guidelines that help us > maintain a certain quality of documentation within the repository. I think the proposal from Stephan should catch all your questions. If not feel free to define and propose them. I agree with have a more clear process for all you are asking. > >> - Should this be part of the Zope Foundation development process > >> (which again seems to be worked out by the Zope Management > >> Organization)? If so, I'll hereby volunteer to join such a > committee > >> and contribute my ideas (especially on package organization in the > >> repository and the associated development process). > > > > I really hope t
[Zope3-dev] Utility registry bug
uot;, line 23, in notify subscriber(event) File "D:\projektCompiler\trunk\src\zope\component\event.py", line 26, in dispatch for ignored in zope.component.subscribers(event, None): File "D:\projektCompiler\trunk\src\zope\component\_api.py", line 130, in subscribers return sitemanager.subscribers(objects, interface) File "D:\projektCompiler\trunk\src\zope\component\registry.py", line 292, in subscribers return self.adapters.subscribers(objects, provided) File "D:\projektCompiler\trunk\src\ZODB\Connection.py", line 732, in setstate self._setstate(obj) File "D:\projektCompiler\trunk\src\ZODB\Connection.py", line 786, in _setstate self._reader.setGhostState(obj, p) File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 604, in setGhostState state = self.getState(pickle) File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 596, in getState unpickler.load() # skip the class metadata File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 459, in find_global return factory(conn, modulename, name) File "D:\projektCompiler\trunk\src\ZODB\DB.py", line 615, in classFactory return find_global(modulename, globalname) File "D:\projektCompiler\trunk\src\ZODB\broken.py", line 181, in find_global __import__(modulename) File "D:\projektCompiler\trunk\src\zope\app\module\__init__.py", line 69, in __import__ fromlist) File "D:\projektCompiler\trunk\src\zodbcode\module.py", line 243, in _import mod = registry.findModule(name) File "D:\projektCompiler\trunk\src\zope\app\module\__init__.py", line 38, in findModule manager = zapi.queryUtility(IModuleManager, name) File "D:\projektCompiler\trunk\src\zope\component\_api.py", line 210, in queryUtility return getSiteManager(context).queryUtility(interface, name, default) File "D:\projektCompiler\trunk\src\zope\component\registry.py", line 132, in queryUtility return self.utilities.lookup((), provided, name, default) File "D:\projektCompiler\trunk\src\ZODB\Connection.py", line 732, in setstate self._setstate(obj) File "D:\projektCompiler\trunk\src\ZODB\Connection.py", line 786, in _setstate self._reader.setGhostState(obj, p) File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 604, in setGhostState state = self.getState(pickle) File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 596, in getState unpickler.load() # skip the class metadata File "D:\projektCompiler\trunk\src\ZODB\serialize.py", line 459, in find_global return factory(conn, modulename, name) File "D:\projektCompiler\trunk\src\ZODB\DB.py", line 615, in classFactory return find_global(modulename, globalname) File "D:\projektCompiler\trunk\src\ZODB\broken.py", line 181, in find_global __import__(modulename) File "D:\projektCompiler\trunk\src\zope\app\module\__init__.py", line 69, in __import__ fromlist) File "D:\projektCompiler\trunk\src\zodbcode\module.py", line 243, in _import mod = registry.findModule(name) File "D:\projektCompiler\trunk\src\zope\app\module\__init__.py", line 38, in findModule manager = zapi.queryUtility(IModuleManager, name) File "D:\projektCompiler\trunk\src\zope\component\_api.py", line 210, in queryUtility return getSiteManager(context).queryUtility(interface, name, default) File "D:\projektCompiler\trunk\src\zope\component\registry.py", line 132, in queryUtility return self.utilities.lookup((), provided, name, default) exceptions.AttributeError: '_LocalAdapterRegistry' object has no attribute 'lookup' Regards Roger Ineichen _____ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE Mit freundlichem Gruss Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot warnings in Zope3 trunk 2.4 remy
The Buildbot has finished a build of Zope3 trunk 2.4 remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by '': Build Source Stamp: None Blamelist: Build Had Warnings: warnings test sincerely, -The Buildbot _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot success in Zope3 branches Zope-3.1 2.4 remy
The Buildbot has finished a build of Zope3 branches Zope-3.1 2.4 remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'fdrake': testing Build Source Stamp: None Blamelist: Build succeeded! sincerely, -The Buildbot _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 zc1
The Buildbot has detected a failed build of Zope3 trunk 2.4 zc1. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'Benji': Test Windows Slave Build Source Stamp: None Blamelist: BUILD FAILED: failed svn sincerely, -The Buildbot _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 zc1
The Buildbot has detected a failed build of Zope3 trunk 2.4 zc1. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'Benji': Test Windows Slave Build Source Stamp: None Blamelist: BUILD FAILED: failed svn sincerely, -The Buildbot _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 zc1
The Buildbot has detected a failed build of Zope3 trunk 2.4 zc1. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'Benji': Test buildbot on Windows Build Source Stamp: None Blamelist: BUILD FAILED: failed svn sincerely, -The Buildbot _______ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
