[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: tracking satellite project's trunks
Jim Fulton wrote: On May 4, 2007, at 6:25 AM, Baiju M wrote: ... We will be using same Zope 3 resources for bug tracking, mailing list and wiki for these satellite project's, is it ? Thanks a very good question. I don't think we need more mailing lists. In fact, I think zope3-dev and zope-dev should be merged. I suspect that these projects will eventually get their own projects in launchpad, but I'm not sure. I'm also not sure about wikis. I don't think we need to do anything about this any time soon. It sounds like we're in the distribution business, and have problems similar to a Linux distribution. Since Ubuntu's requirements are in a large part driving Launchpad development, we should examine what Ubuntu is doing. I got the impression one of Launchpad's underlying goals it to make it easier for upstream (the package developers) and downstream (the distribution developers) to collaborate on critical information such as bugs. I don't know what the concrete status of this is for Launchpad however. I think we should be asking Steve. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
Benji York wrote: Christian Theune wrote: Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could Zope 3 just be a buildout with a configuration that creates a Zope 3 application with a bunch of stock components. Christian said we should wax philosophical and since this one of my favorite activities I will belatedly do this. :) It is instructive to look at TurboGears. They were the pioneers of egg-based distribution and used cool words like 'megaframework' to market the concept of various libraries being integrated into one framework. Django in contrast spreads memes like yeah, megaframeworks are nice, but we're INTEGRATED. So we could market Zope 3 as the integrated mega-framework. :) TurboGears is different from Zope 3 in that most of its component parts are libraries developed by independent communities. This is less the case for Zope 3, though some of its constituent parts are similar (ZODB for instance). As time progresses we might eventually see more smaller communities form around smaller parts, but we'll see. If I read Jim right, we should be careful about splitting up the community prematurely, so let's all keep it on this list for the time being. :) TurboGears is also different from Zope 3 in that there is an actual turbogears package out there. This contains the code that glues the libraries together into a more coherent experience. With Zope 3 the responsibility for a coherent experience is diffused over numerous packages, though one can argue that zope.component and zope.interface play the most important roles here. It's interesting to consider Grok in this light too. Grok tries to encapsulate various patterns of Zope 3 and offer them in a more convenient to use form. In this, it might be somewhat similar to the role the turbogears core package plays, but of course only to people who actually use Grok. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Hi. I know there must be a few folks that would like to easily add other clients or servers to zope (at or after bootstrapping) and have control over the services with the running reactor :-) A simple api for accessing the multiservice after bootstrapping would make zope more accessible to twisted development. Has anyone got any ideas on incorporating this. I have made a suggestion but hoping for input and other ideas to make this happen. The ZopeService class subclasses service.Multiservice. The Multiservice itself provides methods from twisted for adding, disowning, starting or stopping services or iterating over the services in the multiservice. I am hoping we can can come up with a good way to make this object accessible within zope. Many thanks. Regards, David David Pratt wrote: I am wondering if as part of bootstrapping zope, that a utility could not be set up in the site manager that could hang on the zope multiservice object. Methods available for the utility could allow you access to this after booting zope. Is this reasonable? Many thanks. Regards, David David Pratt wrote: Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
