Re: [Zope3-Users] vary formlib render_submit_button by skin
On 4/19/07, Christian Theune [EMAIL PROTECTED] wrote: Am Mittwoch, den 18.04.2007, 17:09 -0400 schrieb Fred Drake: On 4/18/07, Leonardo Rochael [EMAIL PROTECTED] wrote: I was looking at formlib and I found that If i want to customize widgets per skin, I just have to register their view to a different type, e.g.: As you can for all views. However I found no such way of customizing the render_submit_button adapter per-skin. All examples I found of the action renderer declarations are like ... Is there any way of specializing the action rendering per-skin? I expect there to be one since it's html generation, which should be skinnable. It should be, but isn't. :-( I've run up against this as well, and working around it is more painful than it should be. Do you consider it a bug? Is it tracked somewhere already? I think I have similar problem with action renderer: I would like to attach a javascript handler for my action button. Unfortunately the renderer seems to not allow to pass any additional attributes for the html button (like onclick attribute). Leonardo, you mentioned about overriding the renderer adapter. This could also solve my problem, if possible. How to do that? Regards! _ Alek Kowalczyk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] session start/end
Hi, reading through zope.app.session, I couldn't find any built-in support for session_start and session_end events, similar to what existed in Zope2. Are there any recipies for such a use case? Searching the web didn't gave me pointers. And by the way, is it possible to programmatically access the sessions of other users? If so, how would one do this? Of course I'm well aware that security issues might arise. The use case for both questions would be to find out if a user is online, as an information displayed to other users. Thanks, Sascha -- Lalisio - connecting knowledge worldwide Lalisio GmbH Puschkinstraße 1 99084 Erfurt fon +49 (0)361 541 43 80 fax +49 (0)361 541 43 79 [EMAIL PROTECTED] www.lalisio.com Sitz der Gesellschaft: Erfurt Amtsgericht Jena, HRB 113943 Geschäftsführerin: Ute Rother Ust-Id.: DE813237441 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] vary formlib render_submit_button by skin
On 4/19/07, Marius Gedminas [EMAIL PROTECTED] wrote: On Thu, Apr 19, 2007 at 11:20:07AM +0200, Aleksander Kowalczyk wrote: I think I have similar problem with action renderer: I would like to attach a javascript handler for my action button. Unfortunately the renderer seems to not allow to pass any additional attributes for the html button (like onclick attribute). Yes. I recently needed to add a CSS class to an action button (in Zope 3.2 -- there's no time to port to 3.3/3.4 because Customers Demand Features). In the end I subclassed zope.formlib.form.Action and made render a regular method that did what I wanted it to do. Leonardo, you mentioned about overriding the renderer adapter. This could also solve my problem, if possible. How to do that? Reading zope/formlib/namedtemplate.txt might help. You either have to use ZCML overrides, or subclass zope.formlib.form.Action (or attach marker interfaces to its instances, although that might not work given its copy-on-__get__ descriptorish behaviour). Can I somehow override this directive (from formlib/configure.zcml) in my instance's etc/overrides.zcml ? adapter factory=.form.render_submit_button name=render / I think I asked about similar thing some time ago - and the response I received was no... Regards! Alek -- _ Alek Kowalczyk http://iblog.blox.pl ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Zope 3.4.0a1 released
19 April 2007 - The Zope 3 development team announces the Zope 3.4.0a1 release This release introduces support for binary large objects in the ZODB, provides a new postprocessing hook for publishing results and makes all Zope packages available as Python eggs. Development release and feedback This is a development release with alpha quality. It is intended for developers to check their applications for compatibility with the new features. This release *is not intended to be used in production environments*. We'd love to hear about any bugs you encounter. Please use our bug tracker, the mailing lists, and the IRC channel to contact us in case you encounter any problems. This alpha release will be succeeded by a beta which is expected to be available by 3rd May 2007. For status updates on our roadmap check: https://launchpad.net/zope3/3.4/+milestones What is Zope 3? --- Zope 3 is a web application server that continues to build on the heritage of Zope. It was rewritten from scratch based on the latest software design patterns and the experiences of Zope 2. The component architecture is the very core of Zope 3 that allows developers to create flexible and powerful web applications. Compatibility with Zope 2 -- We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 packages. But we're not there yet. **You can't run Zope 2 applications in Zope 3.** New features and important changes -- - Updated the shipped ZODB to version 3.8 and introduced optimized handling for large files in conjunction with ZODB Blob support. Most Blob operations can be handled with O(1) effort now providing a scalable approach to handling large files. - Introduced IResult hook for postprocessing of publishing results. This replaces a similar private IResult hook from previous releases. It is a hook point into which a variety of interesting policies, including in-Zope pipelining, can be placed. See zope/publisher/httpresults.txt for more details, which itself points to the full details for IResult and IHTTPResponse.setResult in zope/publisher/interfaces/http.py. - zope.app.testing.functional.ZCMLLayer supports in-process tearDown. For backwards compatibility, this feature is disabled by default. You can enable it by passing ``allow_teardown=True`` to ``ZCMLLayer()`` or to ``defineLayer()``. - Removed unused and untested SFTP code from zope.app.twisted along with all the SSH keys. Removed all the SSL keys also. - Added new Decimal field type to zope.schema (and DecimalWidget in zope.app.form) and added security declarations for decimal.Decimal objects - Added new Time field type to zope.schema - Change the publication object to abort the current transaction if the transaction was doomed. Related to: http://www.zope.org/Collectors/Zope3-dev/655. There were many more features, restructurings and bugs fixed. Please consult the file `doc/CHANGES.txt` in the release for more information. Downloads - Zope 3 can be downloaded from: http://zope.org/Products/Zope3 Installation instructions for both Windows and Un*x/Linux are now available in the top level README.txt file of the distribution. The binary installer is recommended for Windows. Zope 3.4 requires Python 2.4.3 to run. You must also have zlib installed on your system. Resources - - Zope 3 Development Web Site: http://wiki.zope.org/zope3 - Zope 3 Developers Mailing List: http://mail.zope.org/mailman/listinfo/zope3-dev - Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope3-users - Bug tracker at launchpad: https://launchpad.net/zope3 - IRC Channel: #zope3-dev at irc.freenode.net Acknowledgments --- Much thanks to everyone who contributed to this release: Jim Fulton, Dmitry Vasiliev, Martijn Faassen, Christian Theune, Wolfgang Schnerring, Fred Drake, Marius Gedminas, Baiju M, Brian Sutherland, Gary Poster signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] vary formlib render_submit_button by skin
On 4/19/07, Christian Theune [EMAIL PROTECTED] wrote: Do you consider it a bug? Is it tracked somewhere already? Not a bug, but missing a useful feature. I may have filed an issue about it at some point, but really don't remember. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Interfaces in Schemas
Am Mittwoch, 18. April 2007 23:24 schrieb Darryl Cousins:
Hi,
On Wed, 2007-04-18 at 09:21 -0700, Martin Aspeli wrote:
Hermann Himmelbauer wrote:
Hi,
I wonder if it's possible to define attributes in a schema that
reference other interfaces. For instance, I have a schema for a car and
another one for
a wheel and what I want to do is something like that:
class IWheel(Interface):
type = TextLine()
class ICar(Interface):
model = TextLine()
wheel = ??? of type IWheel ???
wheel = schema.Object(schema=IWheel)
or even better:
wheel = List(min_length=4, max_length=4,
value_type = ??? of type IWheel???)
value_type=schema.Object(schema=IWheel)
What would be really great now is if formlib could handle this and
would automatically set up the needed widgets.
Not sure what it does; I think you'd need to write some custom reference
widget type thing; you can't fill in a wheel, really. :) Where would
the Wheel objects come from?
This tutorial will be enough to get you started with a custom widget for
your List-Object field.
http://zope3.mpg.de/cgi-bin/twiki/view/Zope/KomplexerContent
Ah, that's very nice, thanks!
Tried it out and it seems to work for Objects() in the schema. However, for
Lists(value_type=Object()), I get permission problems:
ForbiddenAttribute: ('__getitem__', [zbsp.fp.Email object at 0x31eed90])
This happens whenever I try to access the list in any way (e.g. mylist[0] or
for i in mylist...). So it seems, I have to declare permissions for this
list - but how? For the generic Python list object?
My permissions are declared like this:
class class=.fp.MyObj
require
permission=zope.View
interface=.interfaces.IMyObj
/
require
permission=zope.ManageContent
set_schema=.interfaces.IMyObj
/
/class
I thought this would suffice?
Best Regards,
Hermann
Best Regards,
Hermann
--
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Interfaces in Schemas
Am Donnerstag 19 April 2007 schrieb Hermann Himmelbauer: Tried it out and it seems to work for Objects() in the schema. However, for Lists(value_type=Object()), I get permission problems: not a real answer, but another hint: http://zope3demos.googlecode.com/svn/trunk/otherdemos/objectsofobjects2/ maybe useful. Cheers, Sascha -- Lalisio - connecting knowledge worldwide Lalisio GmbH Puschkinstraße 1 99084 Erfurt fon +49 (0)361 541 43 80 fax +49 (0)361 541 43 79 [EMAIL PROTECTED] www.lalisio.com Sitz der Gesellschaft: Erfurt Amtsgericht Jena, HRB 113943 Geschäftsführerin: Ute Rother Ust-Id.: DE813237441 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zope.intid and UUIDs
On Apr 19, 2007, at 12:56 PM, Derek Richardson wrote: We've talked a lot about the composition alternative to my idea, but we haven't talked about my idea much. What is suboptimal with the way I'm proposing, other than that it requires changing zope core? Martin Aspeli had some concrete things to say about why subclassing, your proposal, is suboptimal in comparison to composition. He cast it as why composition would be better, which is simply the mirror image. His first point is particularly interesting: the composition approach might let Plone users leverage your code, which introduces it to a large community of users. They (or Zope 2 core? not sure) have their own intid utility. Composition will be simpler, both in the short and long term; or, if you prefer, to relate it to your proposal, the subclassing approach is suboptimal in comparison. Some more thoughts, FWIW: - I suggest that the implementation should be hidden away. One should be able to adapt an object to something like IUUID or IUUIDProvider. That way we can implement a variety of solutions, including a direct key-reference-to-UUID mapping, a intid-to-UUID mapping, a simple annotation, or other approaches. In other words, IMO, the main feature of your package should be an interface (or two, see below). - I imagine you also want to be able to find objects for a given UUID. I'd suggest an interface for that, which is used to look up a utility. Again, the implementation may vary. - In terms of your default implementation, the integer-based approach is interesting as a building block because there may be different integer sources for a given object, not just intids. For instance, I have an app in which I have integer identifiers for virtual objects, which may be fulfilled with different real objects based on current state. One app might want UUIDs to be generated for the virtual object, while another might want UUIDs for the real objects (so intids based on the standard persistent object key references would be appropriate). Or is that a good enough reason to not do it? No, but that certainly raises the bar, as you'd expect. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zope.intid and UUIDs
Derek Richardson wrote: Philipp von Weitershausen wrote: Derek Richardson wrote: I sense that I'm missing the point here. Perhaps you can elaborate on what you mean when you say use and collaboration. I usually know what those terms mean, but I'm not sure I am getting it in this context. The paragraph definitely seems to miss the point, so let me speak code:: class UUIDUtility(Contained, Persistent): def __init__(self): self.uuids = IOBTree.IOBTree() self.intids = OIBTree.OIBTree() def getObject(self, uuid): intid = self.intids[uuid] return getUtility(IIntIds).getObject(intid) def getUUID(self, object): intid = getUtility(IIntIds).getId(object) return self.uuids[intid] I'm omitting several seatbelts and various functions to add/remove objects from the UUID utility, but I hope you'll get the idea. With the composition approach, the actual utility class may be a little shorter than simply copying the whole thing, but I'll still have to copy and just change the names on a bunch of stuff in interfaces.py (IIntIds - IUUIDs, IIntIdsQuery - UUIDSQuery, etc). Perhaps. You could also come up with a shorter/easier/... API, though I see how it is compelling to model after the IIntIds API. And I'll have to copy most of the tests. You better have good test coverage for your utility anyway. That argument doesn't count :). Martin and Gary pointed out other good reasons why not to go with subclassing: the standard intid utility doesn't work in all environments. Apparently in Zope 2 you'll need a slightly differnet implementation. If you just defer to it via utility lookup, your UUID utility might actually work on both platforms, as long as there's an intid utility. It makes things more flexible. The subclasses are pretty much complete as written here and the BaseIdUtility is just a minor abridgment of IntIds. This allows all the interfaces (other than the two empty markers and the events) to be reused between intids and UUIDs and most of the tests can be performed for both, as well. We've talked a lot about the composition alternative to my idea, but we haven't talked about my idea much. What is suboptimal with the way I'm proposing, other than that it requires changing zope core? Or is that a good enough reason to not do it? Your subclassing idea has a lot of appeal to it. To answer your question what's suboptimal about it: you'll have to wait till the next Zope 3 release cycle to actually make use those modifications. Also, like I said above, the composition approach allows you to be more flexible. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Interfaces in Schemas
There is also a Poll example somewhere in the ++apidoc++ which uses the Object schema field Christophe Sascha Ottolski a écrit : Am Donnerstag 19 April 2007 schrieb Hermann Himmelbauer: Tried it out and it seems to work for Objects() in the schema. However, for Lists(value_type=Object()), I get permission problems: not a real answer, but another hint: http://zope3demos.googlecode.com/svn/trunk/otherdemos/objectsofobjects2/ maybe useful. Cheers, Sascha ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Zope 3.4.0a1 released
Is this series targeting Python 2.5? Robert ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Zope 3.4.0a1 released
Robert Hicks wrote: Is this series targeting Python 2.5? No. Martin ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Zope as an XML-RPC *Client*
A colleague is interested in using Zope 3 (and, if possible, Grok) to write a web app whose objects live, not in the ZODB or in an SQL DB, but on the other end of XML-RPC calls. I am unclear how to implement this one. Would an application of this type even have content objects? If not, how would it be architected? Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zope.intid and UUIDs
Philipp von Weitershausen wrote: Martin and Gary pointed out other good reasons why not to go with subclassing: the standard intid utility doesn't work in all environments. Apparently in Zope 2 you'll need a slightly differnet implementation. If you just defer to it via utility lookup, your UUID utility might actually work on both platforms, as long as there's an intid utility. It makes things more flexible. Hmmm. I've looked in Zope 2.10.3 final (the earliest release I may target) and zope.app.intid is the same between Zope 2.10.3 and Zope 3.3.1, except for the presence in 2.10.3 of zope.app.intid-configure.zcml, which is just a slug. Am I looking in the wrong place? Your subclassing idea has a lot of appeal to it. To answer your question what's suboptimal about it: you'll have to wait till the next Zope 3 release cycle to actually make use those modifications. Also, like I said above, the composition approach allows you to be more flexible. OK, yes, this is a problem. I'm targeting on Plone 3.5 (for the final product, not the uuid utility alone), but I'd like to be backwards-compatible with Zope 2.10.x. So, yes, I'll have to provide a complete backwards-compatible package. I've thought about it and decided that these two proposals (subclassing and composition) are partially orthogonal. Half of subclassing is simply genericizing the interfaces; composition is a matter of implementation. For proof, consider that we could have a UUIDs that implements IIDs and defers to an IntIds for implementation, which also implements IIDs. This might reduce the benefits of code reuse, but would still gain the benefit of one set of interfaces (aside from the IntIds and UUIDs markers). So, my plan. I am going to copy IntIds, genericize the interfaces, and split the superclass from the subclass as mentioned. I'm going to do this in my package. I will provide a UUID implementation but not an IntId implementation. That way if, in the future, y'all decide to move towards this in the core, there will be a pre-existing implementation and I'll be ready. You could include just the interfaces, the interfaces and the utility superclass with a new IntIds subclass without the UUID implementation, or you could include everything - it's up to you. And, if you don't, then I haven't lost anything but 15 minutes of time. As for implementation, I'm going to have to think through whether composition is appropriate for my use. Another advantage of genericizing the interfaces is that this is an implementation detail - I may provide two uuid implementations, one that is composed by intid and one that is not. I may also rethink the implementation of the base utility class to see if I can maximize reuse between these two cases. And, having this flexibility will help me later if I run into trouble backporting to Zope 2.10.x. A fun project! The code will be in the Vice project in the Plone collective, for now, in the packages collective.id and collective.uuid. Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zope.intid and UUIDs
Derek Richardson wrote: Philipp von Weitershausen wrote: Martin and Gary pointed out other good reasons why not to go with subclassing: the standard intid utility doesn't work in all environments. Apparently in Zope 2 you'll need a slightly differnet implementation. If you just defer to it via utility lookup, your UUID utility might actually work on both platforms, as long as there's an intid utility. It makes things more flexible. Hmmm. I've looked in Zope 2.10.3 final (the earliest release I may target) and zope.app.intid is the same between Zope 2.10.3 and Zope 3.3.1, except for the presence in 2.10.3 of zope.app.intid-configure.zcml, which is just a slug. Am I looking in the wrong place? Yes, it's there, but that doesn't mean it *works* in Zope 2. You should look at five.intid, which is an attempt to make it work in Zope 2. Martin ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope as an XML-RPC *Client*
On Thursday 19 April 2007 18:09, Derek Richardson wrote: A colleague is interested in using Zope 3 (and, if possible, Grok) to write a web app whose objects live, not in the ZODB or in an SQL DB, but on the other end of XML-RPC calls. I am unclear how to implement this one. Would an application of this type even have content objects? If not, how would it be architected? No. Basically your write a ZODB-less Zope application where the root object is a libxmlrpc server proxy object. That should work like a charm. In fact, I think this would be an *awesome* demo on how Zope 3 can do without ZODB. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope as an XML-RPC *Client*
On Thursday 19 April 2007 22:54, Stephan Richter wrote: On Thursday 19 April 2007 18:09, Derek Richardson wrote: A colleague is interested in using Zope 3 (and, if possible, Grok) to write a web app whose objects live, not in the ZODB or in an SQL DB, but on the other end of XML-RPC calls. I am unclear how to implement this one. Would an application of this type even have content objects? If not, how would it be architected? No. Basically your write a ZODB-less Zope application where the root object is a libxmlrpc server proxy object. That should work like a charm. Well, I should be careful here. Getting transactions right might be very difficult. That would require some serious thinking -- it will probably boil down to your XML-RPC server also needing to support transactions. But aside from that I astill think it would be a cool demo. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
