[Zope3-dev] zope.schema sets
zope.schema.Set currently only accepts sets.Set objects. Anyone object if I change zope.schema.Set to accept py2.4 builtin sets, or if I add a zope.schema.FrozenSet? I don't see any reasonable objections, so I'll probably check this in within a couple of hours if there is no dissent. 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: eggifying zc.resourcelibrary, zc.table and others
On Apr 5, 2006, at 11:03 AM, Martijn Faassen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Gary Poster wrote: [snip] Jim also suggests the new, as-of-this-moment-no-longer-secret http:// download.zope.org/distribution/ as a possible location instead. All Zope committers have the appropriate privileges to scp to this directory. That's where he will be doing his egg work, at least until he thinks we have figured out the best way to make Zope eggs. It can be used a setuptools source. I'm trying to find a way to scp the zc.resourcelibrary egg into it, but I get permission denied when I scp, possibly because I don't know which directory 'distribution' really is on the actual system. /var/www/download.zope.org/distribution Hm, now I get this from scp: Command not accepted and verbose info says: debug1: Sending command: scp -v -t /var/www/download.zope.org/ distribution debug1: Entering interactive session. debug1: fd 0 clearing O_NONBLOCK Command not accepted Apologies for the confusion, Martijn. I checked with Jim. The procedure that Tres described is only for people who have direct access to the machine. The intended use is similar to the following: $ touch gary_test.txt $ scp gary_test.txt [EMAIL PROTECTED]:/distribution/ gary_test.txt 100%0 0.0KB/s 00:00 Any Zope contributor should have privileges to add to this directory (but not to sub directories). Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ILayer deprecation warning on trunk
Looks like it only appears if you run the functional tests separately. $ ~/z4i/bin/python test.py -f Running zope.app.testing.functional.Functional tests: Set up zope.app.testing.functional.Functional in 5.218 seconds. /home/gary/z4i/var/src/zope3/src/zope/app/apidoc/ifacemodule/ ifacemodule.py:78: DeprecationWarning: ILayer: The zope.publisher.interfaces.ILayer interface has been deprecated and will go away in Zope 3.5. iface = getattr(mod, parts[-1], default) 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: [Checkins] SVN: Zope3/trunk/src/zope/app/form/browser/itemswidgets.py The label for the list items widgets could not point to the field, because
On Apr 5, 2006, at 4:14 PM, Kamal Gill wrote: Hmm, I'm inclined to doubt whether IE expects the id and name attributes to be identical. Distinct values for id and name shouldn't be a problem, afaik Wait, someone used shouldn't be a problem in reference to IE? :-) As Benji said, this isn't idle: we've encountered some pain that makes me bring this up. A quick Google search didn't come up with any confirmation, though, so, without further backup, I'm happy to let this lie. 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] eggifying zc.resourcelibrary, zc.table and others
On Apr 4, 2006, at 12:38 PM, Martijn Faassen wrote: Hi there, * does anyone have any objections if I make eggs for various zc.* packages? In svn, this involves adding a setup.py to these packages, and to add a __init__.py to the zc package that they contain (which contains some egg-specific stuff). Sounds great! (I assume the __init__ changes won't cause problems without setuptools around). Jim points out that Nathan Yergler has a script that can generate eggs from zpkg data; you might or might not find that to be easier. It's less of an obvious win with these packages that have little or no zpkg metadata already, but it might still be quicker in some cases (no idea myself). * the setup.py I'll create will only work with setuptools installed; is this a problem? Not from us. You'd maybe get even more warm fuzzies from people by making it not require setuptools, but that limitation doesn't bother us. * what email address should I list for the author of some zc package? this is information that will appear in the cheeseshop. zope3-dev@zope.org * to get the full egg experience, I'd like to have them uploaded to the cheeseshop. I could do this myself, but they're not my packages. Can I? or does someone else want to do this? I'll of course gladly give admin rights for these packages to the real creators. Jim also suggests the new, as-of-this-moment-no-longer-secret http:// download.zope.org/distribution/ as a possible location instead. All Zope committers have the appropriate privileges to scp to this directory. That's where he will be doing his egg work, at least until he thinks we have figured out the best way to make Zope eggs. It can be used a setuptools source. If you want to use the cheeseshop anyway, that's ok too. Thanks Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Vocabulary the next proposal
On Mar 25, 2006, at 5:41 AM, Philipp von Weitershausen wrote: You can, of course, leave this as it is and implement the 'tiks' vocabulary as: def tiksLanguagesVocabulary(context): return LanguagesVocabulary(context, 'tiks') and then register that as a regular IVocabularyFactory utility, in case you're keen on saving lines in Python or just hesitant to create classes. You then need to do a directlyProvides(tiksLanguagesVocabulary, IVocabularyFactory) on the function so that the utility zcml doesn't complain. 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] a plan for widgets?
On Mar 17, 2006, at 10:24 AM, Martijn Faassen wrote: [...] I'm quite interested in knowing more about your plans, and helping you implement things, if only by porting existing widgets over to the new system. I also realize that discussing this kind of stuff over on the mailing list slows down the speed of implementation quite a bit, especially if there's a clear vision in your head of where it should go. But I still want to help. Ugh. Perhaps just drop me a line when you think I could be useful. :-) Thanks, that's a great offer. I hope to take you up on it when I'm ready. Maybe we should have a sprint where I can sit next to you? :) :-) That would be cool too. 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] httpgz in zope.conf?
On Mar 20, 2006, at 9:39 AM, Stephan Richter wrote: On Monday 20 March 2006 09:35, Jim Washington wrote: [...] BTW, I would be glad to see a proposal to add this to the core. I think httpgz is general very interesting to a lot of people. +1 Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
zope.org checkin mailing list Re: [Zope3-dev] a plan for widgets?
On Mar 17, 2006, at 9:13 AM, Benji York wrote: Martijn Faassen wrote: One problem I seem to have is that I cannot find the mailing list to subscribe to to find checkin messages to the zc package. Is there any? I think there is one, but don't know what it is. :) Jim's talked about one. This seems like it ought to be it, but the archives show it to be decidedly dead: http://mail.zope.org/mailman/listinfo/zopeorg-checkins Instead I prefer to get my checkin info via RSS. Here's a decent (and improving) feed of all checkins for the zope.org Subversion repo: http://www.repocaster.com/main/get_feed/14 That's how I've been keeping up 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] a plan for widgets?
On Mar 17, 2006, at 4:08 AM, Martijn Faassen wrote: Gary Poster wrote: [... snip already-answered question (thanks Roger)...] Doing it in the zc namespace is intended to make no assumptions about what happens with zope.app.form; zc.widget probably will have some backwards-compatibility with zope.app.form, but no dependencies. Hm, while redoing widgets to be better and presumably more capable is definitely cool and interesting, some things have got me a bit worried, in particular the no public timeframe and the need for my projects to work with widgets. I have some questions about the new design - how fundamental is this change to be? Will the widgets API change drastically yes and will this require changes in formlib as well? the current idea is that we will reuse the formlib API (the interfaces, maybe even the effective zope.formlib.form module interface) and as much of the formlib machinery as possible. Is this part of the backwards compatibility story? It doesn't sound right if it is, as there would be no point to a new API if the forms machinery would use the old one. Correct. What also got me worried is that the promise of future new widgets may result in the community doing very little for the time being. We seemed to have a little bit of momentum to clean up zope.app.form.browser, but this will now evaporate most likely. It also potentially makes efforts like using Zope 3 widgets with Zope 2 archetypes not very worthwhile right now, for instance. On the other hand, I can see why, if you have clear ideas about a design, you'd want to develop this in isolation and move it to open source later. But it still isn't positive for any community-driven actions. What to do about this? Maybe we should have just been quiet. I expect this is one of those damned-if-you-do-damned-if-you-don't moments. The current backwards compatibility plan is that we'll provide an adapter to let zope.app.form-style widgets work in the new system to do the same kinds of things you can do with them now; you'll only need new widgets if you want to do new tricks with them. Also, it's a goal that it will will be relatively easy to port an zope.app.form- style widget to our interfaces. You also don't know if you'll like what we do. Maybe these answers are motivation enough for some folks to continue with some of the projects you describe. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
CSV vocabularies (was Re: [Zope3-dev] Re: a plan for widgets?)
On Mar 16, 2006, at 11:38 AM, Tres Seaver wrote: [...] Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive source it: zope:vocabulary name=philosophers file=philosophers.csv / We have something like this--except the csv connection is spelled in Python, not zcml--that we have permission to release in our next open source round. It should be converted to an IIterableSource. 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] a plan for widgets?
On Mar 16, 2006, at 11:42 AM, Martijn Faassen wrote: Hey Roger, Great to have you onboard on this! Roger Ineichen wrote: [snip] btw, didn't Gary Poster start a widget refactoring? Good question. I have no idea what the status of all that stuff is; whether anything got merged or not.. At ZC, several of us had enough experience with the zope widgets that we felt pretty confident that we wanted to start again, with a backwards compatibility story. We started, but ran out of steam, and didn't have a driving project for the changes, so we shelved it. We have an upcoming project that will want the changes. Our current plan is to develop what we need as zc.widget or something, and open- source it at the end when it's what we need, in the hopes that some will find it compelling enough to join in the maintenance and further development (btw, thanks, dobe, for the work on resourcelibrary!). No public timeframe. Doing it in the zc namespace is intended to make no assumptions about what happens with zope.app.form; zc.widget probably will have some backwards-compatibility with zope.app.form, but no dependencies. 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] zc.table and zc.resourcelibrary feedback
On Mar 13, 2006, at 10:59 AM, Martijn Faassen wrote: [...] Thanks for looking into this Martijn. We have some internal versions of a sortable zc.table factory that take a different approach, and are not using the client-side part of the zc.table code much at all. If you're willing to look at it and consider integrating it into zc.table, one of us will send you the files privately. You up for that? BTW, I think I listed in the release announcement that both of these packages could use some TLC. Thank you generally for considering giving them some! I would love to see resourcelibrary developed in these directions, fwiw: - pluggable insertion, to address one of the concerns in your original message. I don't remember exactly what Benji and I talked about. Maybe the resources would not be snippets but callable transformations. Maybe we could provide a factory for one kind of transformation which could be combined to effectively get the same behavior as our current transformation? A piece of code could request a transformation, which might depend on other transformations? Maybe this is too general. - order-aware dependency insertion: IIRC, the algorithm for gathering the necessary dependencies doesn't honor order, which may be a problem in some cases. order-aware could get fragile, though--for instance, if one resource says it depends on A and then B, and another says it wants B then A, what to do? Maybe it's necessary to have one spelling for order-unaware dependencies, and another for order-aware dependencies; maybe that itself is insufficient... - lighter-weight insertion into the publishing framework. No one (including myself) has followed up materially on Jim's old discussion of in-Zope publication pipelines. The request approach is heavy, and maybe a WSGI pipeline element is too heavy also. It would be nice to resolve this, though: replacing the request factory is a bit crazy. It's not a priority for us to work on these things right now, but we open-sourced some of the less-polished packages in hopes that others would see their possibilities, as you did, and be intrigued. ;-) 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: keeping attributes abstract
On Mar 9, 2006, at 7:20 PM, Philipp von Weitershausen wrote: http://codespeak.net/svn/user/philikon/rwproperty/ This is nice. I'm going to use it right now. I wish it were available directly in Zope 3 (or that we were fully eggified). Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
On Mar 2, 2006, at 4:58 PM, Michael Kerrin wrote: Hi Gary, On Wednesday 01 March 2006 15:33, Gary Poster wrote: On Mar 1, 2006, at 10:13 AM, Michael Kerrin wrote: so it doesn't get to the locking tests (which will fail) but this is good thing to aim at :-) Hey Michael. What are you planning to do with the locking stuff? I'd like to see zope.locking (http://svn.zope.org/zope.locking/) used, rather than zope.app.locking. It learns from zope.app.locking while also addressing some issues and adding some features. I don't have time to do much about proposing it and integrating it, though. Maybe I can squeeze in a bit next week or week after. Brillant - Locking is next on my hit list, and I am planing on using zope.locking to improve the current implementation. Cool. I have an issue with zope.locking on a collection with infinite depth but I am planing on ignoring this use case for the moment and get the rest of the locking working without any infinite depth support[...] Any ideas on this?, is it feasible or not within zope.locking? It seems reasonable, I think. I'd prefer to do it with some code on top of zope.locking--within the webdav package, for instance--but am not totally opposed to pushing it down into zope.locking. The basic idea would be that webdav would use a special kind of lock token that marked an infinite depth lock (maybe even just directly providing an interface on the existing lock tokens) whenever you wanted to make an infinite depth lock. Then webdav asking are you locked? for a given object would need to not only ask the object but also walk up the parents to ask each of them if they are locked with an infinite depth token. Since the new spec contemplates sub locks--locks within the infinite lock--it seems to model pretty well. The only concern I'd have is that making checks like that into a security policy might be more work than we would want...although the default security policy collects information from the __parent__s, so maybe it wouldn't be too bad. If we did push this down into zope.locking, my current thinking is that I'd like to have the transitive lock search be some additional API, maybe in a separate interface, and not modify any of the current methods. In terms of code alone, though, this seems very doable, maybe even simple. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
On Mar 1, 2006, at 10:13 AM, Michael Kerrin wrote: so it doesn't get to the locking tests (which will fail) but this is good thing to aim at :-) Hey Michael. What are you planning to do with the locking stuff? I'd like to see zope.locking (http://svn.zope.org/zope.locking/) used, rather than zope.app.locking. It learns from zope.app.locking while also addressing some issues and adding some features. I don't have time to do much about proposing it and integrating it, though. Maybe I can squeeze in a bit next week or week after. If Jim successfully gets zc.sharing open sourced today then we have some zope.locking/zc.sharing integration that (as one integration option for zope.locking tokens) can filter so that only people with locks have edit privileges. It seems to work pretty well, but it's also just one way to use the zope.locking tokens. As with zope.app.locking, the locks themselves are purely advisory until you put in some code to make them enforced somehow. zope.locking can do exclusive lock tokens, shared lock tokens, freeze tokens (effectively, no one gets the lock), and can also support custom tokens if you need them. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Visionaire! (All your problems, solved)
On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote: [...] - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. This would meet what I'm looking for...but I don't think I'll be one of the hard ones to convince. ;-) 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] Visionaire! (All your problems, solved)
On Mar 1, 2006, at 11:02 PM, Jeff Shell wrote: [...] Django is killing us on automatic data (not system) administration pages. [...] I didn't follow this, probably because I don't know Django. Do you mean they excel in automatic data entry forms, a la Zope 3 edit forms/ formlib? As in Ruby-on-Rails slick SQL-driven AJAX forms? Or...? 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: [Zope-dev] Two visions
On Feb 28, 2006, at 12:33 PM, Martijn Faassen wrote: Jim Fulton wrote: Are you kidding? No, I'm not kidding. +1 to what Martijn said in this email (not quoting the whole thing to save precious bandwith). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Of the two, this seems more believable. It also may be the best we can do. However, I still don't like it. :-) - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. This is reasonable, though I don't love it. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. This gets to the heart of my concern, I guess (see below). Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. You say that one of the advantages of this vision is that There wouldn't be confusion about 2 Zopes. I'm afraid that's wishful thinking, if you want Zope 5 to include a Zope 3-like web configuration. If you are going to pursue a Zope Five and the artist formerly known as Zope 3 vision, in which Zope is a single clear product, then it seems to me that Zope Five should be one or the other, and that's what books should describe. A Zope 2 derivative a la Five makes sense, given Zope's history and current users. More below. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. There are some--Steve Alexander and Canonical, maybe?--who might not care about anything beyond choosing among the bag of technologies. But I assert with the right of speaking loudly (i.e., I have no way to prove this) that there are many who appreciate the bag of components design who still want to buy into some of the Zope 3 as web application server story. For instance, if you mean by a Zope 2-like application server an Object File System approach then I certainly hope you are wrong. Even though I don't care much about the Zope 3 ZMI, Zope 3 encapsulates some web app design decisions I would be loathe to lose. I much prefer the Zope 3 approach to OFS, with __parent__ rather than acquisition wrappers, a dict interface rather than objectValues and friends, and traversal adapters rather than __bobo_traverse__ and friends. If acquisition and all the rest are on the way to being replaced within Zope 2/5, then...yay? but then how is it still Zope 2 backward compatible? They seem core to Zope 2 to me. And the Zope 3 versions of the decisions inform many Zope 3 component designs. Do you mean that the Zope 3 users don't need Zope 2 cataloging and indexing? Surely not, and yet again moving Zope Five to the Zope 3 catalog seems pretty questionable as Zope 2 backward compatible. And I *much* prefer the zope.index/zope.app.keyref/zope.app.intid combo in Zope 3. Do you mean that Zope 3 users aren't looking for a better designed web app than Zope 2, that looks less long-in-the-tooth (as I've seen blogs call Zope 2), that has more industrial-strength flexibility and hard-won design experience than the current crop of competitors? I don't think so: I assert that developers of a certain inclination are attracted to the cleanliness of Zope 3 as a web app, and not as attracted to the cruft that accumulates in an older, very successful project like Zope 2. Some of those are new Zope developers, and some are prominent older Zope developers. Do you mean that Zope 3 users don't want a robust, battle-hardened web publisher like the Zope 2 publisher? I think many do. So, I assert that many Zope 3 users, who are in it for the bag of components, *do* want a web application server. If I'm misunderstanding you, then, as Stephan said, maybe you could explain more. (Almost done, but still more below) Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) If this is the plan, then I guess I
Re: [Zope3-dev] More information when verifyClass or verifyObject fails
On Feb 24, 2006, at 4:25 PM, Morten W. Petersen wrote: Hi, I'm playing with Zope 3, and I was wondering if it's possible to get more information about why verifyClass or verifyObject fails (on which attribute or method). Am I blind, is it possible to set some options to display it, or is it a missing feature? In both your emails, tracebacks would be helpful. verifyObject/verifyClass (almost?) always gives the name of the part of the interface that it found lacking. It is sometimes hard to parse the exception, I grant. Care to give the tail end of the traceback and the interface? 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] Why does the following browser configuration fail?
On Feb 24, 2006, at 4:27 PM, Morten W. Petersen wrote: Hi, I have the following browser configuration: configure xmlns=http://namespaces.zope.org/zope; xmlns:browser=http://namespaces.zope.org/browser; browser:addMenuItem title=Recipe class=worldcookery.recipe.Recipe permission=zope.ManageContent view=AddRecipe.html / !-- browser:addform schema=worldcookery.interfaces.IRecipe content_factory=worldcookery.recipe.Recipe label=Add Recipe name=AddRecipe.html permission=zope.ManageContent / browser:editform schema=worldcookery.interfaces.IRecipe label=Edit name=edit.html menu=zmi_views title=Edit permission=zope.ManageContent / -- /configure which fails when the two last options are commented out, but works fine when none are commented out. Is there a reason why it fails when the two last .. directives are commented out? On a guess, I'd say that the editform could be commented out without effect. The add menu item probably complains if the page to which it refers (AddRecipe.html) is not actually provided (by the addform). That's just a guess. zcml tracebacks actually do generally have the necessary information to help debug them, actually; it's just not necessarily where you expect. Read up from the bottom of the traceback and I suspect you'll find something helpful eventually, maybe several frames up. If not, try including the traceback in a reply and see if anyone has any bright ideas. 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] More information when verifyClass or verifyObject fails
On Feb 24, 2006, at 4:41 PM, Morten W. Petersen wrote: In both your emails, tracebacks would be helpful. Yep. :) verifyObject/verifyClass (almost?) always gives the name of the part of the interface that it found lacking. It is sometimes hard to parse the exception, I grant. Care to give the tail end of the traceback and the interface? I'm doing it play-by-play from a book, and unfortunately I don't have the code to reproduce it. But as far as I can remember, it just said that the class or instance didn't verify against the interface, without any explanation of which attribute or method it was failing on, which could've been a good thing to know. Cool. The three sorts of exceptions that the verify methods will raise are 'DoesNotImplement' (you didn't actually declare the object to implement/provide the interface; no name is appropriate), 'BrokenImplementation', and 'BrokenMethodImplementation' (both of which include a name, AFAICT in the code). Maybe you got a DoesNotImplement? I could see how it might be confusing. These sorts of questions should probably go to zope3-users, btw. 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: Zope 3 web root
On Feb 18, 2006, at 3:08 AM, Shane Hathaway wrote: In my last project, reusing the ZMI seemed like a good idea. Maybe that was a bad choice. Do you start with an empty site.zcml? I haven't dared yet. :-) We started mostly from scratch, with various successes and failures as we tried to reuse large-scale UI/framework. I'd say that we've generally been happier and more successful reusing lots of small components and small-scale UI bits, versus large framework things like the ZMI (others with whom I work, feel free to disagree ;-). I regard the smaller zope 3 and eliminate zope.app movements as signs that this is a shared feeling. 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] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
On Feb 21, 2006, at 7:15 PM, Philipp von Weitershausen wrote: Dominik Huber wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. [...] I like those simplifications, but I have two little objections... [...] The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. Strong -1 on removing class/implements. We use this frequently to apply policy from one package to a content object in a second unrelated package, from within a third package that depends on both. I'll miss class/factory, but agree that it is an example of the magic you are trying to remove. 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: Zope 3 web root
On Feb 17, 2006, at 6:45 PM, Shane Hathaway wrote: User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes [...] File, [...] . I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. To each his own, I suppose, but I'm surprised you included File in the rant-list. Lots of non-web-design uses want that. We've had our problems with big blobs, but they should be addressed, and in the core, and files should be probably included either in the core or as a well-maintained, highly-used, shared addition. As to the rest, while I think I understand at least a good chunk of the genesis of your statement, I'm glad that the component system *will* allow others to explore ZODB-based TTW dev as an add-on, as you suggested in a later message. You meant it in a derogatory sense, but one could argue that ZODB-based TTW dev got to be so problematic *because* it was so successful. There are strengths there. That said, I'm eager to see what you might think up as an alternative: I think both paths might be fruitful. 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: merge zope-dev and zope3-dev?
On Feb 17, 2006, at 6:26 PM, Chris Withers wrote: Philipp von Weitershausen wrote: We'd have to declare the zope3-dev list for obsolete and make people not send messages to it. We'd just have to define a date and time. All subsequent mail traffic would be handled by zope-dev. Okay, who actually makes this call and how to we set a date? Only you and Philipp were excited about this. Not sure that constitutes a ringing endorsement. Maybe others will chime in now. FWIW, I'm -0. 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] Error quering the catalog with a TextIndex and a KeywordIndex
On Feb 16, 2006, at 6:49 AM, Sasha Vincic wrote: I have made my own i keyword index, it works fine when only querying it but if I query an other index in the same query I get an error. MyKeywordIndex.apply() returns what zope.index.keyword.KeywordIndex.search() returns this is the values that cause the error: [(3, BTrees._IFBTree.IFBucket([(1, 0.15151515603065491), (8, 0.15151515603065491), (12, 0.15151515603065491)])), (4, IISet([1, 6, 8, 12]))] Traceback: ... result = catalog.apply( query ) File /Applications/Zope-3.2.0/lib/python/zope/app/catalog/ catalog.py, line 100, in apply _, result = weightedIntersection(result, r) TypeError: invalid argument That IISet won't work. I have no idea why your index put it there, but it need to be a float to use weightedIntersection. I'm curious as to why the SetIndex in zc.catalog was not generic enough to do whatever you need. It already has tests and has been used successfully for some time now. 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] Last chance to comment on Simplify skinning
On Feb 16, 2006, at 10:52 AM, Benji York wrote: One downside to the expanded interface directive is that it hides the fact that a utility is also being created. I actually prefer the browser:skin version because it totally hides the underlying atomic operations, but the interface-also-registers-a-utility version conflates two atomic operations. That's what it does now. All Philipp's revised proposal does is have zcml expose the 'id' attribute in zope.app.component.interface.provideInterface. AFAICT there are no other necessary changes to do what he suggested (for this part of the story). 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: Zope 3 web root
On Feb 15, 2006, at 4:21 PM, Lennart Regebro wrote: On 2/15/06, Max M [EMAIL PROTECTED] wrote: Remember its the Z Object Publishing Enviroment? Hear, hear! +1 (Which, to be clear, does not mean we shouldn't encourage people making it easier to use SQL in Zope. But our strength and heritage is as an OPE.) 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] Last chance to comment on Simplify skinning
On Feb 15, 2006, at 6:03 AM, Philipp von Weitershausen wrote: Hi there, a while back I wrote a proposal on simplifying the skinning system (http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful feedback which in turn made me update the proposal. Since then I haven't heard much comments. I would like to start implementing it soon, especially since the time schedule has been moved up one month. Please speak up now if you got any remaining comments. Silence is assent :). I guess I'm +0 on your current proposal, and +1 on its goals. I like many parts of it. I didn't like the fact that the zcml ended up being longer. I didn't love that people had to start asking questions about interface types in order to register a skin. Interface types are a cost--another layer of abstraction, another potentially mind-blowing thing to explain. You are already suggesting changing the zcml, and I'd like to see a compromise between the brevity of the current zcml and the conceptual clarity of your proposed changes. I tried to brainstorm, but didn't love what I came up with. Maybe it can take us somewhere. What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType / utility component=.interfaces.ShanghaiSkin provides=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / could become browser:skin component=.interfaces.ShanghaiSkin name=ShanghaiSkin / The rest of your example would remain the same. It doesn't accomplish everything you set out to do, and that's a shame, but it feels like a compromise with a reasonable counter- argument: defining skins is a basic task often introduced early on with teaching Zope, and it's a shame to have to bloat the zcml and teach advanced topics too soon. I'd like to at least get the interface... zcml out of this story. 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: Zope 3 web root
On Feb 13, 2006, at 5:36 PM, Martin Aspeli wrote: On Mon, 13 Feb 2006 07:51:34 -, Chris Withers [EMAIL PROTECTED] wrote: Scripts and RBDMS are the fast food of the web development world, not the salad. Looks nice, tastes great, eventually leaves you fat and unhealthy. ZODB and maybe an ORM is the greens for me, it might not be to everyone's taste at first, but it's the best option in the long run... I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need ad-hoc queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. FWIW, I like this Zope RDBMS vision. 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: One namespace for ZCML
On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: [...] +1 to Stephan's comment, Tres' comment, and Tres' use of the word ukase (which I had to look up). -1 to the proposal. 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: Re: Who would use this crazy thing called Zope 3?
On Feb 11, 2006, at 9:24 AM, Martin Aspeli wrote: On Sat, 11 Feb 2006 10:39:52 -, Lennart Regebro [EMAIL PROTECTED] wrote: [...] There are methods for neatly deprecating things like this, and they have been employed consitently in Zope 3, and quite consistetly in later versions of Zope2. For example, in Zope 2.8 the whole Zope package was renamed Zope2. The Zope.py backwards compatibility handler will be removed in Zope 2.11. I'm not aware of this causing any problems. There are two types of deprecation, though - one is deprecating specific packages or methods or classes. Another is deprecating fundamental patterns and ways of working. Am I supposed to use ZCML for this or Python? Well, a while ago, it was ZCML, now it's python, and then maybe it'll be something that looks completely different. Now I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... FWIW, I personally doubt that we would make the filesystem choice for the vast bulk of ZC's past and future engagements. I would also be surprised if we did not continue to use the ZODB as our primary persistence tool (among others, already including the file system and RDBMSs) in the future. I just wonder how someone who isn't already in the know and on this list would hope to keep up with all these twists and turns. That is - I wonder how those who have deployed on Zope 3 deal with them. We run regular automated tests. We ideally make sure that the changes are ones we agree with or ones we can opt out of. 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: Selecting a code name
On Feb 11, 2006, at 11:48 PM, Philipp von Weitershausen wrote: [...] Indeed. Plus, I strongly feel that pushing Zope 3 more than Zope 2 or viceversa isn't helping. We need to push Zope-the-technology and Zope-the-community. Branding Zope 3 and making it look like something separate now when Zope 2 is actually moving towards Zope 3 feels like a step back. Let's promote Zope. Unfortunately, very few of us appear to agree on what Zope 3 is, let alone what Zope is. 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] Zope 3 web root
On Feb 9, 2006, at 9:25 PM, Shane Hathaway wrote: Roger Ineichen wrote: That's a very interesting idea. It is a very neat idea. You asked for gut reactions, and I must admit that I regard the ZODB as more attractive and more central to the Zope story than some, so my gut reaction is lukewarm. I can imagine sites like the ones you described, though, and have even made one or two that might have used this...though not at work. Come to think of it, maybe it would also be an interesting approach to a baked web site delivery system. 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] Hyping Zope3 contest? (was: Selecting a code name)
On Feb 8, 2006, at 7:53 AM, Lennart Regebro wrote: Now, who can organise this hype-contest that everybody seemed tothink was a good idea? It wasn't a mandate. I got three kinds of responses (publicly and privately): 1 Yes, go for it. 2 If we split it up so that it's not a website contest but a contest for individual elements (logo, copy, concept, layout) then yes, go for it. 3 We're already making an effort on something like this on the zope- web list and elsewhere. (I interpreted this as no, don't do it.) I think the split-up contest--response 2--that Joel Moxley proposed on the list and others proposed privately to me sounds good. If others feel that it would stomp on their efforts, though, I'm not thrilled about angering people who have already spent significant time. I'd like them to step up and be involved, at least to bless the contest, and ideally to be a part of it. If they don't want it, then they should say so and see if we can work out a compromise. We already have two logo entries. :-) If I don't see any conversation or disagreement about this--or an offer from the ones already working on this stuff to organize the contest--then I'll propose an invitation email in a day or two. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Do we really want Zope 3 marketing talk isolated on zope-web?
I'm not sure shuffling the hype and Zope 3 marketing conversations to zope-web is a good idea. I'm not trying to fix zope.org (eek), and I'm not trying to improve the Zope 2 image (though that would be nice too). I, and I think others, are interested in marketing Zope 3. As such, are we really such a big group that we should divide up onto a *third* list (zope3-users, zope3-dev, and zope-web)? I haven't signed up there yet, myself. I feel like going off isolates the people working on the marketing stuff: new blood doesn't see the work and possibly join in; and old easily-annoyed-and-unsubscribed-to-yet- another-freaking-list blood doesn't have visibility of the work. Yes, this has been a lot of email messages, but I'd rather hang out together. Thoughts? 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] Hyping Zope3 contest? (was: Selecting a code name)
On Feb 8, 2006, at 6:34 PM, Martijn Faassen wrote: Gary Poster wrote: [snip] I think the split-up contest--response 2--that Joel Moxley proposed on the list and others proposed privately to me sounds good. I'm not really thrilled about that idea. Marketing needs to be a unified message, and if you split it up you'll likely end up with a hodgepodge. You also risk everybody doing the easy parts and nobody working on the parts that cost some energy. A contest for website ideas (with a bunch of webpages in a layout and with some good text and graphics) sounds better. It's more likely to result in one of more visions we can live with. If you're interested in new names for Zope, logos, and so on, that's fine, as you can present it in the context of a larger message. Currently I'm not at all convinced we need an additional name for Zope 3 or work on the logo, but a good presentation could definitely change my mind. A mockup of a homepage and a bunch of subpages, together with the textual part of the marketing message shouldn't be too big a hindrance to get a few good submissions. You say this in your other message: Somehow people don't seem to be discussing other activities much in the recent threads, such as the writing intro text, of tutorials, designing and presenting screencasts, gathering links and other information. Seems like just the sort of individual things that a split-up competition would be good for, to me. Add in something silly, like most fun logo or silliest slogan, just for spice, and it even sounds like you have a nice balance of categories. Your list also sounds like things that can be done out of the context of a grand website effort, and used as useful raw materials for such an effort. Whatever, I was only volunteering to try and help. I'm beyond, beyond swamped. I'm thrilled that folks are working on the zope.org site. Thank you. Perhaps other loose boutique sites, as I had envisioned, for individual projects such as the Zope 3 effort, can grow at a later time. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Zope Foundation Imminence (was Re: [Zope3-dev] Nine new ZC Zope 3 packages)
On Feb 6, 2006, at 9:52 AM, Chris McDonough wrote: BTW, how impending is impending? Days, weeks, months? Anybody know? The word on the street is a pretty small number of weeks. (I believe the general idea at ZC is to not announce any precise guess as to exactly how impending we think things are, so people don't get mad at us if we miss a timeframe over which we have no control.) 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] Selecting a code name
On Feb 6, 2006, at 2:31 PM, Paul Winkler wrote: On Mon, Feb 06, 2006 at 01:53:29PM -0500, Benji York wrote: Shane Hathaway wrote: Stephan Richter wrote: Okay, I am giving in on this. There is a three step process that will have to be fullfilled to assign a codename to the Zope 3.3 release. I'd say assigning a name is a responsibility of the release manager. As I understand it the codename idea wasn't to have a codename per release (like Ubuntu), but a name in addition to Zope 3 to help differentiate it from Zope 2. I'm +0 on the latter and -1 on the former. Me too. Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3: Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-) 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] Nine new ZC Zope 3 packages
(apologies to Martijn and Stephan for repeating this email: zope.org rejected my previous emails) On Feb 6, 2006, at 6:51 AM, Martijn Faassen wrote: Stephan Richter wrote: On Monday 06 February 2006 06:13, Martijn Faassen wrote: Is this stuff intended to end up in the zope core eventually? If so, what steps will need to be taken? I imagine this also ties into the eggs story, but the question on the zope core perhaps still stands - what would be a dependency of the zope core? In light of the recent discussion at the Plone Snowsprint, there is a general desire to have a common repository for Zope 3 addons that are useful, but might not be appropriate for the core. In my opinion we would like to be able to control the license and quality of this repository. Basically, it should be core-quality/ ready code in an add-on place. Thus, it would also require those packages to follow the Zope 3 development process. I have had positive feedback about this idea from the Plone developers. Also important is regular releases for these packages. Sure. I'd love to. I'm happy if I at least get the stuff open- sourced, though. Life is full of compromises. Released versions do: * publicity * make it clear for which zope version my add-on package release is going to work. Right now it's unclear whether the add-ons are for Zope 3.2, or Zope 3 trunk, or what. FWIW, for this particular example, most of the new ZC ones are developed on trunk, and several of them are also tested on 3.2. No way to know that looking at 'em, I know. Additionally, we should make it easy for people to install these packages in a canonical way. Right now, this is confusing... I had some things to say about general package layout here: http://faassen.n--tree.net/blog/view/weblog/2005/10/07/0 With a package in the 'zope' namespace, what am I supposed to do when I install it? Symlink it into lib/python of my Zope 3 software home? When I have two separate packages in the zc namespace, how am I supposed to install that? I can get it all working of course, but it's non-obvious and there are multiple ways to do it. There should a single obvious way to do it. Sure, if you like. I'm cool with whatever, as long as it doesn't add too much ceremony to actually open-sourcing our code. For those watching at home, one obvious alternative for UNIX-based systems is symlinks; less obvious but cross-platform alternative is using pkgutil.extend_path from the standard library. I'm also worried about putting non-core packages into the namespace 'zope'. It's unclear what ZC's policy is in this; some packages are in the 'zope' namespace, other packages are in 'zc'. And not only ZC is adding things to the 'zope' namespace; there's zope.paste, for instance. We don't have a policy, we have intelligence guided by experience, since we've never done anything like this before. Note that Jim wants to make the zope package in the repository smaller, and divide up the zope namespace into separate projects that can be knit together. We don't know how this will work yet, which is what conversations like yours will hopefully suss out. FWIW, right now generally the zope namespace for us includes things that we (a) know from the beginning that we want to open-source, and (b) are fundamental, things that in the past we would have just added to the repo because we would have been confident that the world wanted them as part of Zope. Maybe we'll do zc packages exclusively from now on. 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] Nine new ZC Zope 3 packages
(Apologies to Martijn for the dupe; again, zope.org rejected my previous mail) On Feb 6, 2006, at 6:13 AM, Martijn Faassen wrote: Gary Poster wrote: [snip lots of cool stuff] Great, more stuff to play with! :) Just saw zope.file; this begs to be combined with hurry.file's smart upload feature, where the server retains the file so that validation feedback forms work with files. ZC has released many other useful standalone projects on zope.org over the past few months, including zope.file, zope.ucol, zope.locking, and zc.catalog. They all are worth a look. What's the thinking about moving some of this into the zope core? Additionally, at Infrae we have the hurry package that contains some stuff that might be useful to fold into the core (in particular hurry.query and hurry.file, combined with zope.file). Proposals for all of this stuff sound *great* to me. We didn't propose it simply because we don't have time. We didn't want open sourcing our code to be contingent on having enough time to make the proposals and do the package rearrangements. Is this stuff intended to end up in the zope core eventually? If desired. Pretty sure that zope.locking, zope.file (once blob support is in), and zope.mimetype ought to go in the core. we have a zope.html that we'll get out soonish too (based in some TIKS integration of FCKeditor--thanks Roger!) that we expect to be in the core. We're not sure if in the core means in the Zope 3 repo: as I said in the other message, check with Jim on that. If so, what steps will need to be taken? Someone will need to propose what they want to merge, and reconcile with Jim what that means in terms of repo and releases. We'll help. I imagine this also ties into the eggs story, but the question on the zope core perhaps still stands - what would be a dependency of the zope core? Did I already answer this? I'd be happy to have most of zc.catalog go in zope, and maybe some other parts of the new packages. It's a combination of what the community thinks ought to be part of a core release; how that will affect our packaging story, as you said; and who is going to do the necessary proposing and knitting. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Re: Re: Please Guido, pick me, pick me!
(...sigh...apologies to Stephan...) On Feb 6, 2006, at 6:35 AM, Stephan Richter wrote: On Monday 06 February 2006 01:15, Brad Allen wrote: By new website, do you mean a Zope 3 advocacy site, or a general documentation site? Making a separate site for advocacy seems like a no-brainer (ala Pythonology.org), but the documentation site is another matter. Have the Zope 3 core developers decided to split Zope 3 documentation onto a completely separate site? Maybe this has already been discussed on the Zope3-dev list, which I haven't yet looked at. Any site, any focus would be good. Anything at all is an improvement! :-) +1. Do what you think ought to be done, and we'll all simultaneously kibbitz wildly and be *very* appreciative. :-) 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] Selecting a code name
On Feb 6, 2006, at 3:26 PM, Shane Hathaway wrote: Gary Poster wrote: Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3: Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-) Well, a new name for Zope 3 sounded like such a bad idea that it didn't even occur to me that someone would suggest it. We'd have to live with whatever name we choose. Arghhh! I'm not sure I could handle the pain. ;-) Release names would be OK because they change often. LOL. :-) I don't feel strongly about it...unless someone who actually makes a marketing effort feels strongly about it, in which case I'm 100% behind whichever way they feel. ;-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Zope 3 Marketing Competition? (was Re: [Zope3-dev] Re: Selecting a code name)
On Feb 6, 2006, at 5:37 PM, Martin Aspeli wrote: [...] This is about getting people to *understand* what Zope is about, to understand that we *care* that they understand and that we made an *effort* to make it easy for them to get into it. It's about lowering the barrier to entry and the risk that they'll spend time learning something that'll turn out to be a dead end. It's about showing off that Zope can be sexy and knock the socks off the competition. It's about generating some excitement, not just a dreary list of technical blather. [...] How about we have a marketing competition? :-) The goal would be to set a date, like end of February or end of March, at which point everyone would submit their entries. Entries would be something like a one-to-three page brochure website. We'd vote...maybe within categories like 'marketing copy', 'layout', 'logo', and 'overall concept'. Winners would have net fame, and we'd put top contenders up on a zope*.org site. Maybe we could do something else small for the winners too? Any ideas? Minimal requirements to get this to happen: - final submission date - enough people committing to have an entry (maybe 10? 15? I think *everyone* potentially has something to offer here, so the numbers would ideally be even bigger...but I won't hold my breath :-) - someone willing to organize - a web site to post the results to. ;-) If the due date is in March or later, I'll volunteer to organize, if there's enough interest and then enough commitments to enter. That said, if someone else wanted to volunteer to organize, I'd gladly hand the reins over. ;-) Is this crazy? 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] Three new Zope Corp packages now developed on zope.org
On Feb 5, 2006, at 10:41 AM, Stephan Richter wrote: On Wednesday 11 January 2006 14:10, Gary Poster wrote: zope.locking: a replacement for zope.app.locking that provides additional features while learning from the zope.app.locking strengths and weaknesses. Could we deprecate zope.app.locking and move the code to zope.locking? +1 with deprecating zope.app.locking and using zope.locking. Move what code? Dependents like zope.app.externaleditor? BTW, on a somewhat related note, if anyone wants some of the zc.* code to be moved into Zope proper (maybe even just the zope.* namespace, and not the project itself), don't assume that the release as a zc.* package means we're against that. Keeping the zc.* namespace was the easiest thing to do, and did not demand refactoring our software, refactoring the core, or making a proposal. If someone wants to champion it and do the work (well, obviously not refactoring our software, but providing a generation to compensate for the name change and whatever else happened), propose it. 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] zope.schema: defaults for non-immutables... questions
On Feb 5, 2006, at 12:20 PM, Stephan Richter wrote: On Tuesday 24 January 2006 12:26, Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) Yes, this is even more apparent with the Datetime object, where you often want to make the default now. That's true. It's been raised before...and changes like this have not been approved by Jim. [...] BTW, I am really glad someone is looking at this code. It has not gotten the attention it deserves. Thank you very much! I add my thanks. But... I really hope you will get checkin rights and check in your suggestions! :-) ...as I said, Jim disagreed with this sort of change the last time it was brought up. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Nine new ZC Zope 3 packages
[My apologies for spamming zope-dev; I neglected to add the 3 in the first post] Zope Corp has released nine new packages as standalone Zope 3 projects on zope.org. Three are completely new to the zope.org repository, and six were previously part of the zc Sandbox on zope.org. These three packages are brand new to zope.org. zc.shortcut Our (second) take on the symbolic link use case. zc.displayname What we use for drawing breadcrumbs and such; a dependency of zc.shortcut. zc.relationship A very new cut at a ZODB-friendly directed graph, based loosely on some old ZC work. These next six projects were already in the zc sandbox, and are now moved to full-fledged projects so collaboration is possible and so we share the state of the art. zc.datetimewidget A datetime widget that uses the now-standard mishoo LGPL calendar widget. zc.extrinsicreference One-way references designed to be back-references for standard attribute pointers. zc.form Some *extremely* useful but sometimes undertested widgets, including timezone widgets and choice widgets that remember the last chosen value per user. zc.listcontainer A persistent linked list that might be more appropriate than ordered container for some use cases. Well tested. zc.resourcelibrary An approach to letting page components dynamically request javascript and css resources during page composition. Wants a publishing pipeline to be able to get rid of a heavy-handed replacement of the browser request factory. Good idea, usable and useful now, but could use more polish. zc.table A very useful and powerful table rendering implementation, including the ability to have table-based forms. It has some rough edges that could use polish. ZC has released many other useful standalone projects on zope.org over the past few months, including zope.file, zope.ucol, zope.locking, and zc.catalog. They all are worth a look. 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] My Experiences using Interface invariants with Formlib
On Jan 30, 2006, at 3:21 AM, Michael Howitz wrote:
Hi, as suggested in #zope3-dev I'll post my experiences with interface
invariants and formlib here.
I have an interface with two password fields which should be equal:
class IUser(Interface):
password=zope.schema.Password(title=upassword)
password2=zope.schema.Password(title=upassword again)
# this Exception is raised when password are not equal
class PasswordsAreNotEqual(zope.schema.ValidationError):
uPasswords are not equal.
# the docstring is shown in UI becuase it is a ValidationError
implements(zope.app.form.interfaces.IWidgetInputError)
# see below why
# this function tests equality
def arePasswordsEqual(obj)
if obj.password != obj.password2:
raise PasswordsAreNotEqual
# set the test function as invariant
IUser.setTaggedValue('invariants': [arePasswordsEqual])
You may already be aware of this and rejecting it for religious
reasons, but it is arguably easier to do this by defining it in the
interface, either with an @invariant or arePasswordsEqual =
invariant(arePasswordsEqual) (invariant as imported from
zope.interface and defined in zope.interface.interface).
Formlib expects Errors raised by invariants to be subclasses from
zope.interface.Invalid (which zope.schema.ValidationError is).
That constraint is actually defined in zope.interface, fwiw.
To dislay the error formlib tries to get a multi adapter which
provides
zope.app.form.browser.interfaces.IWidgetInputErrorView. There is only
one such adapter in Zope3
Yes; generally, we define our own views.
(zope.app.form.browser.exception.WidgetInputErrorView) because it
seems
that all other errors in FormBase's self.errors are implementing
zope.app.form.interfaces.IWidgetInputError or even they are
instances of
zope.app.form.interfaces.WidgetInputError. (Did not try.)
So I implemented zope.app.form.interfaces.IWidgetInputError in my
error
class. (Which really implements this interface because the only method
the interface provides (doc) is implemented by
zope.schema.ValidationError.
If the exception has an attribute widget_title (which is not in the
interface zope.app.form.interfaces.IWidgetInputError but only in the
class zope.app.form.interfaces.WidgetInputError) then the value of
this
attribute is displayed in front of the error message separted by a
colon.
That's arguably a bit of a hack: these aren't widget errors. But
it's a reasonable prototype decision.
The error message is only displayed on the top of the form. Maybe
there
is also a way to get the error message displayed under a widget.
Not currently; the exception would have to have some data to help
this. We don't do this, and formlib doesn't help with it, but it
would be a nice option.
Is this the way it should be done?
As above.
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] My Experiences using Interface invariants with Formlib
On Jan 30, 2006, at 12:11 PM, Jim Fulton wrote: Fred Drake wrote: On 1/30/06, Michael Howitz [EMAIL PROTECTED] wrote: I have an interface with two password fields which should be equal: class IUser(Interface): password=zope.schema.Password(title=upassword) password2=zope.schema.Password(title=upassword again) Gary outlined one approach, but I'll suggest another possibility anyway. If the purpose of repeating the field is only to provide a confirm password field for the user interface, it may make sense to provide a new widget for Password fields that does all that itself, instead of putting that in the data model. At that point, you have only one password field in your model, but the form can still deal with password double-entry in reasonable ways. +10 Yeah, agree. I was addressing the trees, rather than the forest. 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] Bytes versus ASCII
On Jan 27, 2006, at 5:16 AM, Christian Theune wrote: Hi, (this is about zope.schema) I assumed that the fields Bytes and ASCII have some distinction. The ASCII field explicitly checks for every character to have an ordinal value lower than 127. Bytes however does a cast in fromUnicode(u) that does str(u). This will break if there are non-ascii characters in the unicode string. Effectively this makes it an ASCII field as well. However, I don't know enough about the environment, so eventually this is all good. When does the fromUnicode method get called? Everytime I use this field through zope.app.form or zope.formlib? I think it might be leveraged elsewhere, but the big client AFAIK is zcml. ___ 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: ZCML bad ;-)
On Jan 24, 2006, at 12:22 PM, Shane Hathaway wrote: Fred Drake wrote: On 1/24/06, Chris Withers [EMAIL PROTECTED] wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. Are you sure? Perhaps it's reasonable to use a single namespace for all the ZCML directives defined as part of the Zope 3 release. Agreed. Let's just do that. ... Separate namespaces for separate business entities makes sense to me. What doesn't make sense to me is having separate namespaces for every subsystem, which is too deep a hierarchy. I would be OK with that. That seems like it's a reasonable compromise. 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] ZCML bad ;-)
On Jan 23, 2006, at 10:08 PM, Stephan Richter wrote: On Monday 23 January 2006 20:56, Shane Hathaway wrote: Chris Withers wrote: You didn't read what I said... I assert that anyone who binds the http://namespaces.zope.org/zope to anything other than the default namespace, or http://namespaces.zope.org/browser to anything other than browser: will be causing confusion for themselves an anyone else who has to read the .zcml they've generated. As a matter of style, I'd also prefer that the default namespace always be http://namespaces.zope.org/zope. I'll note that I commonly make browser the default namespace in browser packages. FWIW, me too. I'm no XML guru (as Fred will attest ;-) ) but reading the namespaces on an XML file seems like basic XML procedure. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Email proposals migrated to wiki proposals
I moved the proposals I made last week to the wiki. The mapping is listed below. I have implementations for all of them and will probably check them in tomorrow sometime barring further discussion. I did have one qualm with the auth proposal, as I described and implemented it. As before, we are still only keeping track of names of plugins. The masking of utilities by contained plugins seemed likely to be confusing to me. I decided that if that were to change, that would be another proposal, and I wanted to see the work I had already done get wrapped up. However, I'd be interested in thoughts about this, especially once people had a chance to look at it. The current solution has the advantage of being simpler from a data perspective, at least. Also, I'll be including a generation script to make group folders play nicely in PAU's new world order. I plan to make it an automatic upgrade. If it causes any problems for your software then please let me know. Gary mapping of email proposal - wiki proposal http://mail.zope.org/pipermail/zope3-dev/2006-January/017435.html - http://dev.zope.org/Zope3/ AllowContainedNonUtilityPluggableAuthenticationUtilityPlugins http://mail.zope.org/pipermail/zope3-dev/2006-January/017415.html - http://dev.zope.org/Zope3/ FireEventsWhenPrincipalsAreAddedToAndRemovedFromGroupFolders http://mail.zope.org/pipermail/zope3-dev/2006-January/017416.html - http://dev.zope.org/Zope3/ DefineInterfaceForGettingFullClosureOfAPrincipalsGroupsImplementInPAU http://mail.zope.org/pipermail/zope3-dev/2006-January/017419.html - DefineInterfaceForGettingAGroupsMembersImplementInPAU ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Principal Comparison and/or References
On Jan 13, 2006, at 12:18 AM, Jeff Shell wrote:
...
With all of the other principal / group mini-proposals going on, does
there need to be a way to strongly (if that's the right word) compare
a principal looked up from an id that came out of... well, somewhere
(a transaction log record, a string stored in the 'creators' dublin
core sequence, etc), or even against each other?
b3_1 = zapi.principals().getPrincipal('brcms.user.3')
b3_2 = zapi.principals().getPrincipal('brcms.user.3')
b3_1 is b3_2
False
b3_1 == b3_2
False
Comparing the id attribute works. Is it reasonable to assume that
zapi.principals().getPrincipal(request.principal.id) should return the
same principal as request.principal? And thus if
somerecord['creator_id'] == request.principal.id, that's considered a
good match?
Yes. We compare on principal id.
I believe it would be relatively easy to set up your system in such a
way that this would not be safe. For instance, you could have two
sites, both with authentication utilities. If each authentication
utility had the same prefix and had a user with the same key in the
auth utility, then you would have two different users with identical
ids in the system.
Don't do that. :-)
It might be reasonable to add a bit to the IPrincipal interface that
__eq__ is provided and uses id to compare. That seems reasonable to
me, but maybe others have qualms. Care to write a mini-proposal? ;-)
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] proposal: allow contained PAU plugins
Background: The pluggable authentication utility (hereafter called PAU; found in zope.app.authentication) allows two kinds of plugins, credential plugins and authenticator plugins. The PAU currently keeps track of the names that it should use for these two types of plugins, and then looks up utility components by those names. The plugin utilities know of no relation to the PAU, and there is nothing stopping a single utility from being used for multiple PAUs. Principals from authentication utility plugins have ids that are comprised of three components: the PAU prefix, the authentication plugin utility prefix that identified the user, and the identification of the user within the authentication plugin. Primary Problem: Some plugins want to know what PAU they are associated with. They also may only want to be used by a single PAU. For instance, if a authenticator plugin wishes to convert some of its local principal information into a principal or principal id, perhaps to fire an event, it cannot: the PAU is the only component that knows how to do that, in part because of the composition of ids described in the second paragraph of background, above. Another example is that groups folders should only be applied to principals defined in its same PAU: principals defined in sites above will never have a chance to ask the lower groups for their blessing (see zope/app/authentication/groupfolder,txt, the Limitation section at the bottom). Group folders cannot maintain that constraint themselves, because Secondary Problem: It would be nice to not have to do the utility registration dance for local PAU plugins. Tertiary Problem: The PAU is a site management folder, which means it can hold local utilities; it typically is used to hold plugin utilities, and this is a bit misleading. Adding them in the PAU does not do anything unless you register them as a local utility; and there's no difference in doing that in the PAU or in a normal site management folder. The registered plugins can in fact be used by PAUs below the one in which they reside, which is again not obvious. Consideration: Some (many?) plugins *are* appropriate to be shared--credentials plugins are often sharable, for instance. The utility pattern does have merit, and should be maintained. Solution: In addition to utility-based plugins, allow contained plugins, which are looked up by name from within the PAU. Adding a plugin to the PAU would immediately make it available to be used by the PAU, without having to register it as a utility. The id in the container would be the name for the lookup. Container names would mask utility names (i.e., the container names would have precedence). Some plugins would want to only be contained item plugins, some would want to only be utilities, and others might be flexible, supporting use as contained items or registered utilities. Contained item plugins could count on __parent__ being the relevant PAU; if their __name__ was one of the configured plugins in the PAU, then they are active. The PAU's prefix adds the missing link to get a full principal id, and the PAU API adds the missing link to get a principal. PAU UI might not have to change too much, though it would help the tertiary problem if utility plugins and contained item plugins were clearly distinguished in the PAU container UI. The Group Folder would become a contained item plugin. Others might follow. Notes: This is reminiscent of the Zope 2 PAS approach. Risks: Some additional complexity, perhaps. Thoughts appreciated. 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] proposal: allow contained PAU plugins
On Jan 13, 2006, at 6:34 PM, Roger Ineichen wrote: Hi Gary Hey Roger [...] All arguments are Ok for me. Cool. But I think the PAU at all is to complex and this whoul not change. Do we really need such a complex authentication module in z3? Well, I know it has come in handy for us. Also, though YMMV, I find it actually much simpler to understand than the Zope 2 PAS--which was also developed because ZC needed the flexibility. Jim, and then Garrett, I understand, have tried to make the Z3 PAU as streamlined as possible. What does this mean to the queriable sources and their API? I assume you mean, what does my proposed change mean there. Not much, as far as I can tell. The getQueriables method on the authentication utility would use the new approach to get the authenticator plugins, but nothing much would change for the queriables (unless a queriable *wanted* to act differently when it got a plugin found via containment, I suppose). A long time ago I was improving the grant form in z3 and implemented a grant vocabulary based on queriable sources. All I can say about that part is, it's too complex and hard to develope with. Yes, we didn't bother with the PAU queriable source pattern but did a much simpler, less flexible, but more practical one still using the PAU data. There might not be a good one-size-fits-all approach to the problem. Risks: Some additional complexity, perhaps. I'm sure we will get additional complexity. But I can live with that. The only question is, should the PAU be a component where other people can use as a base and develope additional concepts like different UI or is, the PAU is only a core component where only should be used for register custom developed plugins. I guess the real problem is, that the PAU supports only modularity for register own plugins all other parts are implemented as none replacable component and you need some functionality whcih is not implemented right now. Two replies to this. First, in this particular case, the problem was that the PAU design had called YAGNI on this kind of use case, and now I do need it. It was a PAU design problem, and I don't think that it's necessarily an example of the need for more modularity. Second, you might be right anyway that we need more modularity and flexibility; however, I still hold out hope that the design is sufficient, or can be with relatively minor refactoring. The combination of credential plugins, authentication plugins, a malleable principal object, and events and subscribers is pretty powerful; ordered subscribers might be needed eventually, but that's an older and broader topic with old discussion. Also, making the PAU more modular will make it more complex, which was your first concern in the email. There's definitely a tension between flexibility and complexity, and it's worth trying to see what we keep simple. I'm a little afraid that this is not the only refactoring in the next future if we not support more modularity in PAU. You might be right that the PAU will in for a bigger refactoring in the future. For now, I'm happy with trying to tackle it in smaller chunks. Thanks for your thoughts Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Mini-proposal: zope.app.authentication group events
Problem:
We want to perform actions when a user is added to a group, and
possibly when a user is removed from a group. There is no hook point
for this currently in the zope.app.authentication code.
Solution:
Fire events in the zope.app.authentication code when principals are
added and removed from groups.
88
from zope import interface
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal
was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
88
In terms of implementation, it looks like
zope.app.authentication.groupfolder.GroupFolder._addPrincipalToGroup
and
zope.app.authentication.groupfolder.GroupFolder._removePrincipalFromGrou
p are the methods that would fire the events.
Risks:
I am aware of None.
Thoughts?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Mini-proposal: new principal interface in zope.security for full closure of group membership
Primary problem: We frequently want to know the full closure of group membership. The groups attribute of zope.security.interfaces.IGroupAwarePrincipal is a list of groups to which the principal directly belongs. The full closure--including the groups to which the principal's groups belong, for instance--must be calculated by any piece of code that needs it. Secondary problem: The description of zope.security.interfaces.IGroupAwarePrincipal.groups does not sufficiently clarify that it is *not* a full closure. Consideration: zope.security.interfaces.IGroupAwarePrincipal has been around for awhile, and probably should not be materially changed (i.e., to redefine or add an attribute). Solution: 1) Clarify the zope.security.interfaces.IGroupAwarePrincipal.groups description: change from List of ids of groups the principal belongs to to List of ids of groups to which the principal directly belongs 2) Add an additional interface to zope.security.interfaces interface. class IGroupClosureAwarePrincipal(IGroupAwarePrincipal): allGroups = interface.Attribute( 'a readonly iterable of the full closure of the principal's groups.') 3) Make the principals in zope.app.authentication implement IGroupClosureAwarePrincipal. First cut of 'allGroups' would probably be to make it be a lazy property, returning a tuple of the full closure. Risks: Some might be unhappy that allGroups is not a hook point, but a convenience: that is, it will be a full closure, not an opportunity to be clever to redefine how group membership is calculated. Thoughts? 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] Mini-proposal: zope.app.authentication group events
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal
was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple
principals to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which the
principal was added')
principal_ids = interface.Attribute('an iterable of one or more
ids of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from which
the principal was removed')
principal_ids = interface.Attribute('an iterable of one or more
ids of principals removed')
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: zope.app.authentication group events
On Jan 12, 2006, at 7:18 PM, Florent Guillaume wrote:
Gary Poster wrote:
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the
principal was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the
principal was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple
principals to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which
the principal was added')
principal_ids = interface.Attribute('an iterable of one or
more ids of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from
which the principal was removed')
principal_ids = interface.Attribute('an iterable of one or
more ids of principals removed')
+1
Cool.
But why the ids and not the objects themselves?
It's driven by the interfaces and implementations around it . Since
Zope 3 generates the principal objects on the fly and actually only
manipulates principal ids for the persistent data, a number of
situations will not have objects already created for the pertinent
principals. Therefore this is just what falls out naturally.
Wouldn't it allow for more flexibility?
You can always convert an id to a principal (if it's a valid id) so I
don't think so.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Three new Zope Corp packages now developed on zope.org
I just moved development of three Zope Corp packages from our internal repositories to the zope.org repositories. We're relying on all three of them. zc.catalog: extent catalog with end-of-transaction indexing; set indexes; value indexes; date indexes; stemmer for the standard zope text index, using (an old version of :-( ) Andreas' TextIndexNG stemmer wrapper. Was previously in the zc sandbox on zope.org. zope.locking: a replacement for zope.app.locking that provides additional features while learning from the zope.app.locking strengths and weaknesses. zc.i18n: primarily included because it is a dependency for zope.locking.browser. We have some common time and duration helpers in there right now, underdocumented. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] mini-proposal: make unauthorized exception view smarter
Problem: The view for the unauthorized exception (zope/app/exception/browser/ unauthorized.py/.pt) gets the authentication utility to issue a challenge, and then draws a page. Drawing the page is silly in some cases, and problematic in others. In particular, for session credentials, the user is redirected to another page because she received an Unauthorized exception on this one: there is no need to draw an unviewed page for the redirect request (and I think we don't care about browsers that can't handle a redirect request). Moreover, if the metal macro page that wraps the drawn page itself raises an unauthorized error, the redirect can be overridden. Solution: Make the unauthorized view smarter: call the authentication utility's unauthorized method before rendering the page, and if the request then has a 303 status, don't bother to render the page. This is simply the default view, so if someone really cares about a browser that doesn't support redirects, they can register one more like the one we have now. Risks: Requires more developer work to support browsers that don't support redirects. Thoughts? 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] Ajax in Zope 3
On Dec 6, 2005, at 5:35 PM, Tarek Ziadé wrote: Gary Poster wrote: ... I have old proposals for this, and some revisions of them on the basis of conversations with Jim, Fred, Stephan, and Benji. ... ... I am looking forward for the proposal revision :) Just a heads up that I am unlikely to be able to get to this anytime soon. Sincere apologies for being all smoke and no fire on this. :- ( Please work on the AJAX Zope 3 story! :-) 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] RFC: abolishing python: expressions in ZPT TALES
On Dec 28, 2005, at 5:00 PM, Igor Stroh wrote: Rocky Burt wrote: ... Its my personal opinion that anytime a page template requires logic complicated enough to warrant using a 'python:' expression, that logic should be re-thought and placed into a view class. ... First, I have sympathy with those who want this to be a documentation change, possibly with a permanent default-but-configurable warning, rather than ripping out the feature. I think python: has been around too long to change without a full reinvent TAL for 2.0 or switch to an competing templating technology discussion. It's too much a part of standard in-the-trenches TALES usage. +/-0 I'd give it a +1 if TAL would support boolean operators :) Second, I agree with Igor than booleans are the time when I still pull out the python: bit of the TALES toolbox. If we remove or deprecate python:, I'd like to have a replacement. The other replacements people have mentioned for the python: feature are list item access and calling with arguments. I don't care as much about the list item access, but wouldn't object to it. I'm opposed to a new TAL syntax that allows calling with arguments: that's the core of the python: feature, and what many are opposed to. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Finished zope/i18n/format.py XXX (was Re: [Zope3-dev] XXX Roundup)
On Dec 19, 2005, at 2:41 PM, Gary Poster wrote: On Dec 17, 2005, at 4:06 PM, Gary Poster wrote: On Dec 16, 2005, at 4:20 PM, Benji York wrote: Gary zope/i18n/format.py:141 and 149 Update, if anyone needs to follow along: ... This is fixed in trunk and 3.2 branch. Thanks to Stuart Bishop for his feedback and help. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] why security proxy the modules for a menu item directive?
zope/app/publisher/browser/menu.py, line 132, security proxies the 'modules' name. This is pretty annoying, and seems unnecessary to me for a zcml filter: trusted filesystem code. Anyone want to defend it? 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] XXX Roundup
On Dec 16, 2005, at 4:20 PM, Benji York wrote: Gary zope/i18n/format.py:141 and 149 (Not entirely sure why Benji blessed me with this assignment ;-) , but...) As I wrote before, this is an evil bug caused by a misuse of pytz code: timezones in this code can be pickled, but then not unpickled, so they lie in wait, waiting to explode next time you try to get the object . Exciting! Jim and I have agreed that the best way to approach this is to offer a patch to Stuart for an intelligently-persistable offset-based timezone, such as that found in zope.app.datetimeutils, and then use that in the 18n code. I don't have time for that this weekend, and there's no guarantee we could even get an ok from Stuart for this in time. I also have an approach that pukes when you try to persist one of these timezones, but then some of the timezones returnable from the method are persistable, and some not: another fairly evil trap. If someone else has desire and time to tackle this, go for it. If not, I'll try to do it on Monday. Stuart, if you happen to read this, giving your blessing to such a patch would be very cool. ;-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
zope.i18n.format pytz usage (was Re: [Zope3-dev] XXX Roundup)
On Dec 16, 2005, at 4:20 PM, Benji York wrote:
Gary zope/i18n/format.py:141 and 149
Yup: the pytz StaticTzInfo is being used in a non-API way, and while
pickling works, unpickling doesn't (ew!).
Here's the interactive prompt example, if anyone cares.
import pytz.tzinfo
tz = pytz.tzinfo.StaticTzInfo()
import pickle
import datetime
delta = datetime.timedelta(hours=-5)
delta
datetime.timedelta(-1, 68400)
tz._utcoffset = delta
pickle.dumps(tz)
'cpytz\n_p\np0\n(Ntp1\nRp2\n.'
pickle.loads(pickle.dumps(tz))
Traceback (most recent call last):
File stdin, line 1, in ?
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
1394, in loads
return Unpickler(file).load()
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
872, in load
dispatch[key](self)
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
1153, in load_reduce
value = func(*args)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line
163, in _p
return unpickler(*args)
File /home/gary/z4i/var/src/zope3/src/pytz/tzinfo.py, line 340,
in unpicklertz = pytz.timezone(zone)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line 47,
in timezonezone = _munge_zone(zone)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line 71,
in _munge_zone
return zone.replace('+', '_plus_').replace('-', '_minus_')
AttributeError: 'NoneType' object has no attribute 'replace'
This is not pytz's fault: it wasn't designed to work the way that the
format module is using it, as Stuart points out following Philipp's
'XXX'.
I think I can fix it by using the pytz.reference.FixedOffset class.
That's what I'll try to do now.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: zope.i18n.format pytz usage (was Re: [Zope3-dev] XXX Roundup)
On Dec 16, 2005, at 4:56 PM, Gary Poster wrote: ... I think I can fix it by using the pytz.reference.FixedOffset class. That's what I'll try to do now. BTW, let me note that this is still bad. These things *should not* be persisted: they will generate lots and lots of little instances. Maybe the code should use a class that refuses to be persisted instead. Another approach would be to copy over zope.app.datetimeutils into zope.i18n: it has already addressed the problem. 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] Interface implementation declaration weight (was Re: View lookup changes in Zope 3.2?)
On Dec 14, 2005, at 4:56 AM, Dominik Huber wrote: Gary Poster wrote: I'm pretty sure there's a proposal on the wiki somewhere with Jim's full lookup algorithm that you want, but the iro for the pertinent object(s) usually gets me far enough. That might be the proposal you mentioned http://dev.zope.org/Zope3/ ComponentArchitectureSimplification Yes, looks like it. :-) Thanks Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
page postprocessing (was Re: [Zope3-dev] Re: XUL, DHTML)
On Dec 13, 2005, at 10:11 AM, Benji York wrote: Jeff Shell wrote: I think there was a proposal for smart widgets that could require Javascript but have the supporting Javascript library loaded only once..? What's become of that? That sounds like zope.resourcelibrary (http://www.zope.org/Wikis/ DevSite/Projects/ComponentArchitecture/ResourceLibrary). We're using it in products and the proposal had enough support to get into 3.2 but a combination of Jim not liking some implementation details... The answer we expected to give to the improved implementation details hinged on the page postprocessing proposal Jim made. http://mail.zope.org/pipermail/zope3-dev/2005-September/015812.html http://dev.zope.org/Zope3/PublicationPostProcessing My impression is that Jim felt that this didn't fly: there was not enough feedback for him to proceed. I may misunderstand. In any case, it didn't happen. Anyone want to take up the ball in the conversation again? Personally, I wanted to just put exactly what Jim discussed into place and see where it led. I was afraid that too much discussion of what we ought to do and well if we do X, then we should Y would kill it: we should just do the proposal, and *then* discover what we ought to do. Bueller? 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] logout patterns: a small proposal
I plan to do this tomorrow, in the silence means consent vein. Want to refresh your memory? http://mail.zope.org/pipermail/zope3-dev/2005-December/016887.html Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: page postprocessing (was Re: [Zope3-dev] Re: XUL, DHTML)
On Dec 13, 2005, at 9:32 PM, Gary Poster wrote: I sent this out too hastily. See below. The answer we expected to give to the improved implementation details hinged on the page postprocessing proposal Jim made. It was not a proposal, but a brainstorm. http://mail.zope.org/pipermail/zope3-dev/2005-September/015812.html http://dev.zope.org/Zope3/PublicationPostProcessing My impression is that Jim felt that this didn't fly: there was not enough feedback for him to proceed. I may misunderstand. I don't think we proceeded past brainstorm to proposal. In any case, it didn't happen. Anyone want to take up the ball in the conversation again? Personally, I wanted to just put exactly what Jim discussed into place and see where it led. ... My position should perhaps be taken at least as a straw man. I'd like to see something like this worked out. I suppose I should try to come up with some details, concerns, or solutions on the basis of Jim's document, and work them out here. How about some other people do that too? :-) 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] Potential bug of intid
On Dec 11, 2005, at 4:23 AM, Tadashi Matsumoto wrote: Hello I was looking into the following code of intid's __init__.py. ... I think it is better to use, for example, 2**30 instead of 2**31. Looks like a good catch to me. Also looks like 2**31 -1 would be sufficient (typical sys.maxint), rather than 2**30...or maybe just sys.maxint (though I wouldn't be surprised if the author had consciously rejected maxint for database portability). By the way, there is a probability (less than 1/2**31 percent) of generating same intids, if thread switching occurs between the line 114 and 115. At which point you should get a conflict error, which in Zope would cause one of the transactions to be retried without the user's knowledge and everything would still be good. 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] Potential bug of intid
On Dec 11, 2005, at 11:00 AM, Tadashi Matsumoto wrote: On Sun, 11 Dec 2005 08:30:06 -0500 [EMAIL PROTECTED] wrote. ... No it wouldn't, because intid will increase. Ah yes, true: I neglected that part of what was going on. Jim's reply is more to the point. At which point you should get a conflict error, which in Zope would cause one of the transactions to be retried without the user's knowledge and everything would still be good. Generating same intids does not always mean a conflict error. Why not? AFAIK it will. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] logout patterns: a small proposal
There are a surprising number of components in zope.app designed to help with logging out. They are all trying to solve the problem that some authentication can't log out, so you shouldn't show logout links then. I only care about the pluggable auth in zope.app.authentication. Therefore what I want is a way to determine whether the credentials plugin used supports logout. I want this to be dynamic, responding to TTW configuration of the pluggable auth, which the current zope.app solutions are not. Jim suggested that a subscriber to principal creation event might scribble an attribute on the (transient) principal object that indicated that the credentials plugin used to create the principal supported logout. This would be easy to do, light-weight, robust (i.e., even in the face of multiple active credentials plugins), something that I could do without committing the zope project to the solution, and easy to use (my tal could do something like tal:condition=request/principal/canLogout|nothing). The problem is that the principal creation event does not include the credentials plugin used by the authentication. The easiest way to approach this, given the current pluggable auth design, is to add a 'credentialsPlugin' attribute on the info object passed to the principal creation factory. The 'credentialsPlugin' attribute would have a reference to the credentialsPlugin used, and would be assigned by the authentication utility. This is a solution because the event fired already includes the info object. Pros: - It enables a more dynamic and much simpler story for determining whether an app can support logging out than the current pertinent zope.app code (as long as you only use pluggable auth). - It's a one-line change to the code itself (not including interface and test changes). No grand architecture changes. - the 'info' object seems to be a reasonable place to add information about the process used to create the principal. - It's ignorable, for those that wish to ignore it. Cons: - This is the only use case I know of for the behavior, so it has a small feel of 'scratch an itch'. Maybe that's not too bad here. Thoughts? 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] logout patterns: a small proposal
On Dec 8, 2005, at 10:58 AM, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 10:11:46AM -0500, Gary Poster wrote: | ... Sounds good to me. Cool. Only one issue that you should have in mind, and that has bitten me several times with the Zope 2 PluggableAuthService is the following: If you use the 'HTTPBasicAuthHelper' for login, that doesn't mean you can use it for logout. That is specially true if you happen to use the 'CookieAuthHelper', which translates cookie-based credentials to http basic. What happens is that it in PAS, if you call logout() it will call all the 'ICredentialsReset', however if the HTTPBasicHelper happens to be one of those, it will raise a 'Unauthorized' exception, because that's how you log someone out using http basic auth, and then two things happen: 1. The cookie credentials don't get erased because of the Unathorized 2. Any plugins that happened to be enabled for ICredentialsReset won't fire. Thanks: that is interesting, and answers some idle questions I had lying around in my head. In the case of the Zope 3 pluggable auth, though, there are a number of reasons why this (currently) doesn't come into play. A particularly pertinent reason is that the default basic auth plug-in doesn't do the 'raise Unauthorized' trick--it just rolls over and plays dead (i.e., 'pass'). Logging out is effectively not available if you are logged in via the standard basic auth. This is a case in which you would not want to offer 'log out' in the UI (or you'd want to work out some other compromise). Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Nov 30, 2005, at 2:18 PM, Chris Withers wrote: Gary Poster wrote: Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on Zope 2. A very good point, but one which makes me feel that Zope 2 shouldn't be merged in with Zope 3 ;-) Actually, yes, all of my points were made to that end--so AFAICT you are agreeing with me, not disagreeing. :-) 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] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Nov 23, 2005, at 10:16 AM, Philipp von Weitershausen wrote: Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ ReuniteZope2AndZope3InTheSourceCodeRepository I already spoke with Philipp on IRC about this, but for the record, and speaking personally, and very arguably selfishly: -1. I think it will place too much burden on the small group of Zope 3 developers, some (many?) of whom do not develop or use Zope 2. Yes, I understand the corresponding response is that Zope 2 devs would theoretically contribute more to Zope 3. If the merge happens, I suppose we'll see if Zope 2 pollutes Zope 3, doesn't affect it, or helps it. Arguing about the future is a tough job. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
While I don't agree with the +1 voters, I understand and appreciate their arguments. That said... On Nov 23, 2005, at 6:49 PM, Jens Vagelpohl wrote: People keep telling Zope2 developers that the inclusion of Zope3 doesn't mean you have to touch it, if you don't use it it is just inert code that won't cause any change in your Zope2 development style. Ok, I accept that, no problem at all. But why should this be any different for Zope3 developers, obviously including Zope2 code would mean exactly the same thing for them. Come on now. ...this is not true. Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on Zope 2. Therefore, making a change in Zope 2 cannot affect functionality in the slightest, let alone break a test, in Zope 3. The same cannot be said of the reverse. Zope 2 devs don't have to touch Zope 3 unless they want to leverage some cool new feature--in which case they are Zope Five devs, probably. Zope 3 devs must touch Zope 2, in this new world order, whether they want to or not, when changes break the stuff that Zope 2 has leveraged. To grant a point to Philipp's argument, it's possible that changes that break Zope 2 are non-backwards-compatible changes in Zope 3 that should have been caught. But consider this story: a Zope 3 dev changes something and deprecates an API. As part of the dev's responsibility, the checkin also makes all code in Zope 3 use the replacement API. Now Zope 2 works, but is generating deprecation warnings whenever the deprecated API is called. Is it the Zope 3 dev's responsibility to change Zope 2 to eliminate the deprecation warnings? What about in the following release when the old Zope 3 API is eliminated--whose responsibility is it then to fix Zope 2? If you view Zope 2 as a downstream client of Zope 3, you probably give one answer; if you view the two projects as a mingled whole, you probably give another. The question here is effectively whether all Zope 3 developers must become Zope 'Five' developers. As you said, Zope 2 developers can choose to proceed essentially unaffected. Zope 3 devs could not. 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] __init__.py interfaces.py guidelines?
On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote: There is another place where there seems to be two different patterns too: sometimes we have: import zope.schema name = zope.schema.TextLine(...) and sometimes: from zope.schema import TextLine name = TextLine(...) FWIW, a third is from zope import schema which I often do for zope.component, zope.interface, zope.event, and zope.schema. I'm not weighing in on the style issues. 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] hurry.query in Zope 3.2?
On Oct 28, 2005, at 6:18 AM, Martijn Faassen wrote: Hey, Martijn Faassen wrote: Would there be any interest in merging hurry.query into Zope 3.2? Apparently not, or at least people are lacking in time, which is understandable as I do too. :) I'll try in more advance for Zope 3.3. We find it very useful here at Infrae, but of course it works just fine as a stand-alone library too. Hi Martijn. Although I'm very interested in hurry.query, yes, I don't have available time right now to look at it. You asked about zc.catalog in your original message, I think. Yes, I'd like to have some of that merged into Zope 3, or at least the ideas discussed, but I don't have time for the necessary proposals right now. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ I think this fixes our security proxy issues. Gary, that's cool with you?
On Oct 26, 2005, at 10:26 PM, Stephan Richter wrote: Log message for revision 39662: I think this fixes our security proxy issues. Gary, that's cool with you? Yeah, I'll take it. ;-) Thanks a lot! 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] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 11:23 AM, Dominik Huber wrote: ... IMO it is very important to provide a standardized way to handle complex, formbased views properly (- prefix like nested widgets) Agreed. FWIW, this is another part of the subview package. I tried to spell this out very explicitly. If contentproviders agreed on the subview interfaces, or something like them, then we would have a lower level agreement for all of the page component technologies out there. and to sketch the difference between widgets and viewlets out. The zope.widget package in the branch is currently in disrepair, but the intent is for widgets to be subviews. The subview package actually grew out of the widget work. This won't be ready for 3.2. I personally don't think that I want default widget look-up to require (context, request, view), as opposed to the current (context, request), so I'd be in favor of widget interfaces extending the subview interfaces, not the contentprovider interface. If for some reason someone wanted a widget system with lookups based on contentprovider then that could be an additional layer, still using all of the (context, request)-based code. 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] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 12:08 PM, Stephan Richter wrote: On Saturday 15 October 2005 15:48, Gary Poster wrote: I also really wish we could agree on a subview-addressing story (for AJAX) and a drag-and-drop story. We have experience with our drag and drop story, and are proposing a new AJAX story for subviews. The subview package only sets up some small foundations so that these can work. This is the reason we have not fully explored implementing portlets yet. I think those type of features are only interesting in very dynamic, CMS-like applications. For example, currently I do not need any of this for SchoolTool. Understood; as mentioned, the subview package offers an underlying agreement, which is important for interoperability. It shouldn't require SchoolTool to do much of anything except perhaps the subview container interface... I'll think about that some more. The persistence use cases are real and important, and I'd like to agree on them, but - we're still having internal discussions about the right way to do it, - it's intended to be an optional part of the subview capabilities, and - it doesn't appear to be pertinent to the viewlet or contentprovider approaches. I really think that sub-views need to be adapters and their state should be stored using a well-defined API. More than that I cannot say, because I have not thought about it. :-) Jim agrees with your assertion, to my knowledge. I am on the fence. Benji disgrees, last I checked. I have certain goals, which I hope to talk through with Jim and also offer up here on the list when I get to it. 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] RFC: Content Providers and Viewlets
On Oct 15, 2005, at 9:52 PM, Roger Ineichen wrote: [...] The content provider package offers just the API for collecting additional content. This pattern can be used directly in python or in page templates. There is no reason that we have to use a viewlet implementation for this. The content provider package offers also a TALES directive called providers. This is only the way can use content provider directly in TAL. Since a viewlet depends only on the page template implementation, there is no reason to merge this two packages together. The viewlet package provides only a standard implementation where we use in relation to the page template concept. Since I use another template language (expermimental), I see no need for the viewlet package. This was my main reason for spliting the content provider and viewlet part in two packages. Let's say the content provider package offers the concept and the viewlet package offers a implementation which depends on page templates. OK, that makes sense. The contentprovider package offers up two bits, then: the pattern of looking up by (context, request, view), and the TALES directive. It sounds like your division of contentprovider and viewlet was directly to support your use of another template language--which is not going to need the TALES directive? But that sounds fine. The most important part of my reply, though, is that I hope we can agree to share an even lower-level interface than contentproviders. If we do, it will address my remaining concerns (expressed below). I will take a look at your Readme next week ... OK, cool. 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] RFC: Content Providers and Viewlets
On Oct 15, 2005, at 8:24 AM, Stephan Richter wrote: ... What are we looking for? - Comments on the Python API. - Comments on the ZCML API. - Comments on the ZPT API. - Use cases that you might think are not covered by the design and implementation. - Whatever you like to say about it... Hi Stephan (and Roger :-). I have read the contentprovider README and skimmed the viewlet README so far. viewlets look like a clever pattern. I can see that they can be applied to many use cases; I'll have to think about them to see how much I like the application compared to others we have used, but I have a generally favorable impression so far. contentproviders are a subset of the viewlet pattern, obviously. But when do you think one might build contentproviders and not viewlets? Do you have concrete use cases (or even current uses) for this division? The most important part of my reply, though, is that I hope we can agree to share an even lower-level interface than contentproviders. If we do, it will address my remaining concerns (expressed below). I have been working on a subview package off in another branch. It addresses a class of bugs caused by subviews that affect non- contained subviews; sets the stage for AJAX components and for independently-configurable drag and drop between subviews; and wants to contemplate subview persistence as an optional addition. Of these, my biggest concern is the first. When building our portlet system, we discovered a class of rendering bugs that occur when a change to a subview affects other subviews (usually non-nested): the underlying data changes as expected but it is not drawn to screen because the data change was out of order for the rendering. The two stage approach, calculating all state and then rendering all, is the solution we came up with for mitigating what we called 'update bugs'. We have significant experience with the two stage approach, and it is our best answer so far. You do not do this, or have another solution I can see that addresses the same problems. We would want this. I also really wish we could agree on a subview-addressing story (for AJAX) and a drag-and-drop story. We have experience with our drag and drop story, and are proposing a new AJAX story for subviews. The subview package only sets up some small foundations so that these can work. The persistence use cases are real and important, and I'd like to agree on them, but - we're still having internal discussions about the right way to do it, - it's intended to be an optional part of the subview capabilities, and - it doesn't appear to be pertinent to the viewlet or contentprovider approaches. The rough README is here: http://svn.zope.org/Zope3/branches/ f12gsprint-widget/src/zope/subview/README.txt?view=auto . The whole package is rough; I had to put work on this aside, but it it is currently slated to be my next project, since we need some of the capabilities. If we could agree on everything but the persistent bits for the 3.2 inclusion then I'd be thrilled. That will mean a number of things have to align though, including our perspectives. :-) 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] Keening for the poultry
Hey Tres. I apologize for not looking at your efforts so far, but just in case I can help quickly, have you seen this, and is it pertinent? http://mail.zope.org/pipermail/zope3-users/2005-September/001078.html 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] zcml:condition registry?
On Sep 30, 2005, at 2:25 PM, Fred Drake wrote: The last time we discussed the zcml:condition attribute for ZCML, we decided that there should be a general registry of feature names that should be checked when defining a new feature name. I think that I suggested a page in the Zope 3 wiki as the registry. A generally accessible web page has some advantages--it is easy to read, and usable even if you don't have the most recent version of the software, for instance. It has some problems too. The biggest problem is that the registry is not maintained or found within the source code: you have to look elsewhere to get the current state, even when you are working in the code, and you also have to go someplace else to edit it. Another is that our web site is sadly not in shape to be a good tool: using a wiki is always a bit annoying, and especially so at zope.org these days. I propose that we actually store the registry in the Zope code, probably in the package that defines the 'condition' attribute. We even get a bit of web presence, thanks to svn.zope.org, for free. A point that lands in either camp, depending on your position, is that the wiki only requires site membership to edit, while the repository approach gates it to contributers. For what it's worth, I'd further say other shared 'virtual registry' type uses that spring up should use a similar pattern. 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] zcml:condition registry?
On Sep 30, 2005, at 6:29 PM, Fred Drake wrote: For the record, Gary capitulated via IM rather than by email to the list. (I didn't even have to force his hand... wonder if he's feeling ill?) I'm send this email to: 1. Give Gary a chance to say Oh no I didn't! in public. :-) 2. Let people know the truth of the matter. :-) LOL 3. Note that I'm setting up the registry in the wiki at: http://dev.zope.org/Zope3/ZcmlConditionFeatures :-) Thanks, Fred. 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 addForm
On Sep 25, 2005, at 3:58 PM, Christian Lueck wrote: ... zope.app.container.interfaces.IAdding seems most promising -- but what to do with it? Question: Is it right to register a formlib-based addview with the browser:page-directive? Yep. How do I get the + ? ;) The '+' is an implementation of IAdding. You first need to register the page for the interface, a la browser:page class=path.to.your.view.class name=addWhatever.html permission=zope.Public for=zope.app.container.interfaces.IAdding / and then register a menu item for the adding that points to it, a la browser:addMenuItem title=Whatever factory=path.to.your.whatever.factory permission=zope.Public view=addWhatever.html / The factory is used to get the interface to check constraints. You might be able to do without it; check APIdoc if you are curious. 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] _notifyOfCopyTo
On Sep 26, 2005, at 2:10 PM, Stephan Richter wrote: On Monday 26 September 2005 13:36, Florent Guillaume wrote: In Zope 3, is it worthwhile to have a kind of ObjectWillBeCopied/ Added event for that, or do you guys feel that this kind of vetoing should be done by simply subscribing to ObjectAddedEvent or one of its friends? I think this is a good event to have. And the way event subscribers can veto is by raising a user exception. We have this zope.app.dependable package, but it will not work for this use case; maybe this code needs some new thought. I believe this is still the final goal for this sort of story: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ ActionPlans Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.recorder not in 3.1c3
I saw in the CHANGES for 3.1 that we Added the HTTP request recorder, which lets you inspect raw HTTP requests and responses. It can be used to create functional doctests without requiring third- party tools such as TCPWatch. Is this zope.app.recorder? I think so. If so, it appears to be in the 3.1 branch, but not in the c3 release. :-/ While I'm delivering potentially bad/annoying news, using zopectl logtail in the release couldn't find the log file; you have to specify it, at which point any benefit over 'tail -F' evaporates (and also at which point the old behavior has changed, AFAIK). I'm not necessarily suggesting we need a c4, but reporting. 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] browserDefault uses '@@' for containers
On Sep 22, 2005, at 1:36 PM, Garrett Smith wrote: Why does z/a/container/traversal/ContainerTraversal include '@@' in the default view name? This is not the case in SimpleComponentTraverser (z/a/publication/traversers). Is there something special about containers that their default view should be an explicit view lookup? Or should SimpleComponentTraverser also include '@@' in the default name? I believe that the idea is that the container traverser wants to specify that the default view name is a view, not an object in the container. That is, if the default view is named index.html, and I have an object in the container named index.html, './index.html' will traverse to the object in the container while @@index.html will render the container view named 'index.html'. Sometimes you *want* the over-ridable behavior (and so you can configure it that way), but the default configuration is to have the system honor the configured view. An educated guess as to intent. :-) 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] Resource Library Proposal
On Sep 16, 2005, at 6:15 PM, Garrett Smith wrote: On Friday, September 16, 2005 3:58 PM, Gary Poster wrote: You could also be asking about the pipeline ideas, but that's not my first guess. :-) Yes, I suspect this is what I'm missing. Maybe so. Maybe you just disagree. :-) In a later email, you and Benji discuss how this might be used for dynamic JavaScript. Benji made the point that that is not what we are talking about. I agree with him, but I think I see your confusion. We expect that the pipelining ideas will lead to a reasonable way to transform output. We hope to leverage that for the resourcelibrary. You could certainly leverage the method yourself, for your own means. The resourcelibrary use case is one of the simple stories that is pushing pipelining--a much larger and more exciting development, I think--along right now. To explore your use case further, though, I'm not sure why you would need something like resourcelibrary for dynamically generated insertions--that is, JavaScript code that the server writes differently for each request. You can just include that inline. The resourcelibrary makes sure that you only include a single instance of the necessary libraries, makes sure that CSS is at the top, as it has to be, and so on. These combined requirements led us to the current approach. There was an earlier post about Ajax. It seems an entirely new approach would be needed to solidly support Ajax. I.e. we would need an architecture that let components interact independently of the browser view, or at least could be accessed in isolation of a full page rendering. Is this the sort of thing the 'pipeline' approach is getting at? No. Pipelining is about taking what the Zope publisher spits out, and then transforming it before returning it to the user. For instance, views might spit out an XHTML snippet, and pipelines would wrap it. Or views might spit out XML of data only, and pipelines would make transform it into a UI. Or views might spit out non- string objects, which would be transformed. And so on. I don't think Ajax needs an entirely new approach--at least what I would mean by an entirely new approach. :-) I'm working out some proposals for that in the new widget code that was started in the sprint. I'll hope to talk about that soonish (though I have a number of other projects I have to wrap up before I get to that :-/ ). The use of ajax libraries will benefit from something like resourcelibrary. Other than that the two are not that related. To get back to your concerns about the resourcelibrary (and conclude), it is currently a drop-in component (from which you can easily opt out) and the pipeline plans should make that even more the case. You'll just be opting out of any shared rich widgets and shared composite page projects that use it. Since you've forked the widget code, it sounds like that sort of thing might not phase you. :-) 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] newer versions of zc.catalog available?
Martijn Faassen wrote: Hi there, We're trying to hunt down a weird bug that is probably our own fault, but it's pretty obscure, and we want to exclude the possibility that any of this has to do with zc.catalog, which we're using (the SetIndex component). The version in the sandbox is 6 weeks old; have there been more recent bugfixes in this component? Hi Martijn. I'm having computer issues--writing from another box--but to my knowledge we have not made any substantive changes since the release. If one of us have not verified that by tomorrow, please bug me. Gary regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/gary%40zope.com ___ 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: Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
On Sep 7, 2005, at 9:13 AM, Florent Guillaume wrote: Jim Fulton wrote: I think that sources are different than initial value. I really don't see any role that initial value has in an object specification. A schema is a specification for an object that provides the schema. An initial value doesn't constrain or specify the object. If anything, it constrains applications that create the object, but in a rather unclear way. But a schema is useful for more than specifying the values of an object. All notions of schemas I've encountered (CPS Schemas, XML Schemas, Archetypes) use the schema to constrain or validate an existing object, yes, but also to create new objects from scratch (even in the absence of widgets). Being able to specify initial values is quite important there. Hi Florent. FWIW, after I argued with Jim about this a bit more verbally last week, he told me that he's willing to keep 'default' around for now, and we'll argue about this again later (maybe when the schema field redesign happens). He doesn't believe that 'initial' is a better word than 'default'. Maybe he just is saying that it is not better enough to warrant the change. I'm leaving both the discussion and the attribute name alone for now. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Drop-in rich (JS/CSS-dependent) view components: Please review (was Re: [Zope3-dev] Resource Library Proposal)
Benji posted this last week and we don't have any feedback yet. We would really like some, even if it is to ask us to clarify what the heck it is about. Some of our other code that we want to contribute depends on this. The use case for this tool is to allow rich view components, such as form widgets (but there are many other examples), that rely on JS and CSS to work in a more componentized, drop-in way. It is centered on the idea of reusable client-side libraries--such as pdlib, the mishoo calendar, prototype, ricoh, mochikit, epoz, kupu, fckeditor etc.--that many view components may want to use, without knowledge of the other view components, but coordinated with them. For instance, imagine you have a widget that wants to use the mishoo calendar JS library. That involves JS and CSS, and CSS is only legal in the head (some browsers allow it elsewhere, yes). You want to package up your widget as a drop-in component for use in applications. Without the tool, you have to tell client developers to explicitly include the JS and CSS on the head of the main form template: not exactly drop-in, especially if the widget is sometimes drawn and sometimes not. With the tool, when/if the widget is rendered, it simply requests that the necessary necessary JS and CSS be included in the head. Further, imagine that you have another widget that needs the same library. Sometimes, they might be drawn on the same page. This tool makes sure you only get the library once (I believe browsers handle this for efficiency, actually, but still this is reasonable). Further, imagine that you need a library that relies on another library (Ricoh on Prototype, for instance). One view component needs Ricoh, and another needs Prototype. This is also handled nicely. The current implementation uses a custom request/response pair to do the HEAD rewriting; this is arguably a bit hacky, and we will probably explore WSGI pipelines once they are available. This should be largely transparent to developers relying on it. Later plans for this include optionally compressing JS and CSS. We think this will allow for a much nicer rich sub-view (i.e., rich widget, among others) story. We're eager to get some feedback, including ideas for improvements. Gary On Aug 31, 2005, at 3:55 PM, Benji York wrote: I've added a proposal for Zope 3.2. Read at http://www.zope.org/ Wikis/DevSite/Projects/ComponentArchitecture/ResourceLibrary. WARNING: zope.org exhibiting some serious caching strangeness, so please comment on the list instead of the wiki. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
