Re: [Zope3-dev] small problem in zc.page?
Fred Drake wrote: On 7/7/05, Martijn Faassen [EMAIL PROTECTED] wrote: I hope that moving it into the zope package doesn't mean it will be only maintained for Zope 3.2 (as it requires python 2.4). While I obviously don't expect it to be released with Zope 3.1 I hope we can pull a release of it that can be installed into Zope 3.1 (as long as it's running Python 2.4). Our current plan is to keep it as a separate top-level project in Subversion, and link it into Zope 3 using svn:externals (similar to zope.testing). Sounds good. I am looking forward to being able to help out zc.page's further development (though so far I only ran into relatively minor snags). Note that zc.page does contain a (very small) quantity of ZCML and that zope traditionally doesn't contain ZCML; what's the thinking about that? 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] Re: interaction between LocationProxy and IIntId utility
Tres Seaver wrote: [snip] I find the same pattern creeping into my work: content objects need to be policy free, which means that they can't do things like emit events, because whether and when to emit them is policy. For instance, if your content objects have setter methods (or properties as sugar on top of them), such methods can't know whether they are the only / last one to be called for a given interaction, and therefore whether they can safely / efficiently emit a modified event. Hm. Having to separate out policy such as event sending out from the content object does make it harder to start out with just a few classes of mostly Python code (that do not care too much about the framework yet) and then refactor them into more components later when the time is there. I like being able to start out with relatively few entities in the beginning and being able to wait and see where the pieces make most sense later on. I imagine this is also a pattern many beginners would start out with; after all rich classes are the pattern in Zope 3. While such classes do not care a lot about the framework yet it'd be nice to allow them to send events and so on. Anyway, I'll just have to gain some more experience building Zope 3 applications to see whether this is a real problem or not. Likewise, content objects don't seem (to me, anyway) to know enough to handle their own renaming; rather, such handling needs to occur in conjunction with the container (and perhaps the ContainerProxy that wraps them). Though it's fairly easy to make content objects in charge of their own naming by letting them implement INameChooser (they do often have to discuss things with their container to see whether the generated name already exists, though). 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] small problem in zc.page?
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: Christian Theune wrote: [snip] I'm actually interested in what the plans/needs for zc.page are to move into core. Maybe I/we can spend some time on bug fixing ... Even if not in the core, it'd already help if this wasn't a one-time snapshot but a SVN repository where we can check in. I wanted to get it into better shape before moving it to the Zope repository, but that is looking silly. I'll try to find time to move it this weekend. Thanks! This raises the question of what it should be called. I'm thinking it should move to the zope package, but page seems a tad too general a name. Thoughts? No ideas on a better name right now. I hope that moving it into the zope package doesn't mean it will be only maintained for Zope 3.2 (as it requires python 2.4). While I obviously don't expect it to be released with Zope 3.1 I hope we can pull a release of it that can be installed into Zope 3.1 (as long as it's running Python 2.4). In that sense it being a separate package outside of Zope 3 may actually make things slightly easier for now, though I won't argue this too strenuously. Sorry, my mentioning the zope package, I didn't mean to imply that it would go into the Zope3 svn project. I plan to make it a top-level project (like zope.testing). If and when it gets copied or linked into the Zope3 project is a separate question. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] interaction between LocationProxy and IIntId utility
Benji York [EMAIL PROTECTED] wrote: Jim Fulton wrote: We don't want to *require* objects to provide ILocation. I don't know what the right answer is here. I'll think about it. I'd love some good suggestions. Perhaps an ILocation adapter that would keep the __name__ and __parent__ information in a separate place (attribute annotations, or a BTree somewhere). So, instead of things getting proxied when they don't provide ILocation, they would instead be adapted. I was about to propose that too, just do object = IContained(object) and let adapters do what's needed. That may be too naive, I don't know... Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ILocation vs IContained
I'm having a hard time grasping the reasons why we have both ILocation and IContained. class IContained(ILocation): Objects contained in containers. But ILocation provides a __parent__ already, which seems to imply that it's contained in it. No? What use case makes us differentiate between the two? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in catalog code
[Dieter Maurer] Restrictions are fine when they are either * enforced (I know BTrees do not enforce the no mixed key types restriction) * clearly documented I do not know whether the ZODB 3.4 BTrees interfaces document the restriction (this would be a good place, I think) Hopefully, they do ;-) No, they don't. Patches accepted 0.5 wink. There are many ways to get in trouble with BTrees (mixing key types is just one), and the ZODB Programming Guide has pages of discussion of potential pitfalls (including mixing key types) already: http://www.zope.org/Wikis/ZODB/FrontPage/guide/node6.html (and a copy of that in PDF format is shipped in every ZODB release). I don't think mixing key types is, e.g., more important than the other ways to create an insane BTree, and I don't think pages of discussion fit sanely in interface docstrings either. This is something that belongs in documentation. Since it already is covered in the only official ZODB docs, I'm not inclined to do more than that. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] how to start zope3 on windows
I downloaded the zope3 package Zope-3.1.0b1.win32-py2.4.exe and installed it. but I don't know how to start it, anyone can help newcomer _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
