Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Chris McDonough wrote: On Nov 24, 2005, at 8:37 AM, Martijn Faassen wrote: I recall a slightly different discussion I was involved in. I remember Zope 2 core developers worrying about the inclusion of Five in Zope 2.8; they were worried they'd need to maintain its codebase. I was one of these people. Since then, I've completely changed my mind; it was a pure win. It makes me happy to hear that. Thanks! Regards, Martijn ___ 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
Paul Winkler wrote: On Thu, Nov 24, 2005 at 11:03:35PM +0800, Philipp von Weitershausen wrote: I'd love to participate in some sprints on these. Me too. PyCon Dallas 2006 is only 3 months away and would be a great opportunity for such sprints. There's nothing about Zope here yet: http://wiki.python.org/moin/PyCon2006/Sprints I plan to attend and I would really love to sprint on further fivification of zope 2. That'd be really cool. p.s. No, I can't volunteer to do any coordination work for this. I'll already have plenty to do preparing for my two (Five-related) talks. Cool to hear you're giving Five related talks. Is there any description of these available online? (not that it's likely I'll be able to attend PyCon, but I'm very curious) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote: Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository I am -1. If I could I would veto this proposal. Here is why: To be totally honest, I really, really don't care about Zope 2! I'll debate with you this reason. I don't think that this changes your dislike of merging the repositories and this argument is on a side-track and not intended to convince you of this. What my point is here is that your attitude about Zope 2 is wrong: as a pure-play Zope 3 developer you *should* care about Zope 2. Some of us have been doing quite a bit of work of bringing Zope 3 to the Zope 2 world. I believe that at least partially as a result of this, Zope 3 is getting a lot more attention from Zope 2 developers. I think that this attention is extremely valuable to the Zope 3 project. There is an awful lot of experience, skills and knowledge in the Zope 2 world that is immensely valuable to Zope 3 developers. We *don't* have a full respresentation of these extremely valuable perspectives in the Zope 3 development community right now. If Zope 2 developers get the impression that core Zope 3 developers don't give a shit about Zope 2, they may not be so likely to actually come on board. That would be a disastrous development indeed. We really need an increased connection between the Zope 2 world and the Zope 3 world. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Gary Poster wrote: 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. I like this third style option, import the last module, and then use the dot notation, and I tend to move towards this pattern in most of my code. Sometimes of course importing the one class is more convenient. Rarely do I use the full dot notation. The benefit of the third option is that it cuts down on your imports and keeps some namespace information in your code without having to do a lot of typing nonetheless. For cases like schema and for instance, hurry.query, there are cases where the same name in the module is referenced many times in the same file, and in that case I may be more inclined to import the name directly without any module prefix. I don't think using any of these patterns is a big style problem (I'm much less opinionated about this than about code in __init__.py); it's hard to recommend a single practice, so perhaps we shouldn't. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Hi there, Jean-Marc Orliaguet wrote: are there any guidelines / best practises for setting the contents of __init__.py, interfaces.py, and the packages that they import or that they expose? there are too many alternatives and too many ways of ending up doing circular imports and I'd like to have a consistent pattern for reducing that risk. but there doesn't seem to be a 100% clear pattern to follow when looking at the zope3 code base: some packages in have all the implementation code in __init__.py, others have it in a file and the imports are done in __init__.py, others import files starting with an underscore (to make them private I suppose). I personally very much prefer __init__.py to be as empty as possible. I like namespace packages. For me it's always a doubletake when I realize most of the implementation of some Zope 3 package I'm trying to understand is actually hiding out in __init__.py, so I don't like this practice. some packages have an interfaces.py file others have a interfaces folder, others have the interface definitions in the implementation code itself ... The pattern changed over time during Zope 3 development. In my current opinion, interfaces.py should usually be able to accomodate all the interfaces of a package. If interface definitions are to be 'private' then they can be in the implementation code, but such privacy is very, very rare in practice. Jim mentioned to me that only public and official interface definitions should be listed in 'interfaces', the others should be defined inline with the implementation - are there guidelines to follow? Don't know. I think the best rule would be to make the interface public unless you have a very good reason not to do so, not the other way around. I like the inline option because it reduces the amount of imports and the risk for import cycles. Does it mean that interfaces should be defined inline with the code and those that are official be imported from intertaces.py? It sounds like a good pattern. With this pattern, the chances are increased people will point to the interface through two different paths, and the chances are increased that people forget to import things to interfaces.py even though they should. It's also an extra indirection; people looking for the interface referenced in some ZCML file discover that in fact they need to go to another module yet again when they look it up. I tend to stick all my interfaces in interfaces.py. I believe keeping interfaces at least somewhat separate from implementation is valuable. It also makes for an easy place to go to to actually find out what interfaces are defined by a package -- I don't have to go read all the source code to see what interfaces exist. You can posit documentation tools that create such a list of all interfaces, but I like my code being inviting to all comers, whether or not they have particular tools. If you really like the other pattern of sticking interfaces together with implementation code, then perhaps don't import them into interfaces.py and don't add an interfaces.py at all. This way things will at least be clearly defined in one place only. I don't really think the public/private divide between interfaces is strong enough to worry too much about hiding certain interfaces. My recommendations for any guidelines would be: * use namespace packages, so nothing (or very minimal stuff only, like a few imports) in __init__.py. I think this is recommended practice outside of Zope 3 as well, so we should stick with this. Twisted seems to have small or empty __init__.py packages for instance, and so does PEAK, to compare with some other large frameworks in Python. * use interfaces.py and put interfaces there unless there's a very good reason it should be private (which is rare). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Jean-Marc Orliaguet wrote: OK, so to summarize this thread: - __init__.py files are empty unless for the convenient import of other modules located in the same package or in a subpackage? I'm typically okay with this, though I suspect it can in some cases lead to circular imports you may not otherwise get, and makes finding what's defined harder than if you directly import from the place things are defined. It does make things more convenient however, in some cases. - public interfaces are stored in interfaces.py - private interfaces are written along with the implementation code Right. And point taken from both you and Jim: sometimes you have private interfaces and you don't want to commit to supporting too much API. - what about file names with an underscore at the beginning? They are used in zope.schema for instance Hm, if I see a module with an underscore I definitely don't feel very inclined to import *anything* in it from my own code. I don't use underscore modules a lot in my code, though sometimes if some code is only implementation detail to support some other module, it's not a bad thing to do. - what about import paths inside a same package: relative or absolute? from mypackage.interfaces import ISomeInterface or: from interfaces import ISomeInterface I prefer absolute. It makes changing the package root harder, but this is not common in practice, and it is much less error-prone in the end as any namespace issues are avoided. If I call my module 'xml' and I do a relative import I may have a problem; I don't want to even think about it :). When Python grows a way to do explicit relative imports then I'll think again. Thanks for this thread! I hope this information will be put on some web page somewhere eventually. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] hurry.query in Zope 3.2?
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. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] hurry.query in Zope 3.2?
Hi there, Would there be any interest in merging hurry.query into Zope 3.2? What it does: hurry.query - higher level query system built on top of the Zope 3 catalog. Some inspiration came from Dieter Maurer's AdvancedQuery. See src/hurry/query/query.txt for documentation. Here's the code: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/ And here's a doctest: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/query.txt Of course, it probably needs a review and adaptations before it's accepted, and time until the feature freeze in november is short. It would be a very useful addition to Zope 3's featureset, however. It exposes features of various indexes that the normal catalog API does not expose, or if so, only very obscurely. :) Now that I think of it, exposing the ZCTextIndex properly with the various features involved may need the most work. If there's interest, I'd really appreciate volunteers for putting up a proposal on the wiki and integrating it into the codebase. This way it'd get a review by that person. If it'd be up to myself I likely won't have time... By the way, is zc.catalog up for merging with Zope 3.2, or won't this happen yet? hurry.query has a dependency on zc.catalog, though I believe I succeeded in keeping this optional. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 11 October 2005 12:41, Philipp von Weitershausen wrote: If anyone here really needs WYSIWYG, please make a point, but I doubt that there will be one... It's a top priority for Jim. Uwe and I agreed we would prefer ReST. I got the impression from Jim that this was just an idea that he wanted to try out. Ideas you're eager to try are different than top priorities, right? Unfortunately having a wiki page in HTML and in ReST is rather incompatible; while you can translate ReST to HTML, HTML to ReST would at best be unreliable and confusing. This means HTML pages can only be edited as HTML ever. Then again, I'm interested in seeing how the idea would work. Whether that should be driving a Zope 3 site as a whole is another question. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Hey Mats, Thanks for joining this discussion! Mats Nordgren wrote: My name is Mats, I've visited #zope-dev under the nick gnosis. I've long been a fan of Zope but very inactive in the community. I'm not much of a programmer and always had a hard time grepping Zope2. Zope3 has made great strides to develop simple stuff like content object etc, I still have a hard time with more advanced stuff like workflow, memberships, catalog (I know these might seem like trivial stuff to the likes of you ;) These things are never trivial to me at least; don't underestimate yourself there by overestimating others. :) I've spoken to J1m and emailed Stephan and asked if there was anything I could do with helping this along, ideas, organization, editing, etc. I'm with Martijn that the site should itself be marketing for Zope3 technology and should be geared towards all levels of knowledge on Zope technology. Great to hear you're offering to help! Perhaps you and I should just get together and try to write up some texts. Drop me a mail if you like. I'd love to see a much more extensive section with how-tos, recipes, and tutorials. If I can conquer Zope we should have hit the bottom of the proficiency scale :) Perhaps I can get there by helping with those specific sections. Great idea! My first contributions to Zope back in '99 or so were in the Zope Documentation Project. Stephan Richter also was heavily involved in this back then. Would there be any chance that a message board could be included directly on the site for support? Perhaps take Stephan's messageboard tutorial? This would showcase Zope3 and add more layers of support. Perhaps this could be synced with the zope-user mail list? Just make it easier to get quick help without the somewhat tedious process of getting running on the list. It's something to consider, though I'd like to set the technology requirements for any new Zope 3 site as low as possible, so that we don't have an excuse from doing stuff. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope3 website report?
Uwe Oestermeier wrote: Martijn Faassen wrote: I'm very curious to see what work was done on a Zope 3 website at the Neckar sprint. Can someone send a report to the list? We (Dominik Huber, Tonico Strasser, Gregoire Weber, and I) set up a zope3org package (http://svn.zope.org/zope3org/) with the following parts: wikification - A wiki view that transforms sets of HTML documents within in a nested folder structure into a Wiki. We defined no special content types. We decided to use only files and folders to be able to work via ftp, fssync etc. as much as possible. comment - A simple comment implementation that stores list of comments in an object's annotations. kupusupport - An integration of Kupu into Zope3. Defines an editor that can be selected from the ZMI menu. We started that from an older version of the IsarSprint and still have to do some work to support the current 1.3.1 version of Kupu. importer - a wget like tool that allows to import existing Wiki pages or other HTML documents from any URL. The pages can be post- processed to extract the content and strip out navigation, etc. This tool Cool stuff! Thanks for this report! I see mostly technical stuff was done. Especially things like comment and kupusupport should also be useful in completely different projects. Has work been done on a reasonably slick layout for the website as well or is this still planned? Has an analysis been done what the goals are of this new site? The Zope 3 wiki has traditionally been mostly a developer's tools to handle proposals and the like. It's also functioned as documentation, but in my opinion wasn't very accessible, and positively intimidating for beginners. As goals for the site, at least the top level of it, I'd suggest marketing, and developer marketing primarily. We need to put across that Zope 3 is powerful, cool, easy, extensible, and built on the vast amount of experience with web application development that we have as the Zope community. Developer marketing also means that we need to demonstrate all the things Zope 3 can do for you, i.e. features. It also means we need to make clear there's a strong community, and thus we need to show how to get involved, with mailing lists, irc channels, svn repositories, and the like. Developer marketing also means there needs to be quick access to easy to follow tutorials, and access to reference material when needed. We need to make the learning curve easier. In this sense the Zope 3 site will also have the goal of being tutorial and reference. Another goal of the site could be to replace the current wiki, i.e. a tool used by Zope 3 developers to talk about proposals, designs, etc. This should however be carefully split off into a special section that people won't accidentally stumble into. We don't want a newbie to browse around and unexpectly run into a half finished proposal on ContainerAdapterSecurityProxyFactoryRegistration. :) Anyway, I'm volunteering to help out with the text and basic organization of this site. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope3 website report?
Hey Philipp, Philipp von Weitershausen wrote: [snip] Here's my 2 cents, even if I might be too late (but hey, when should I have brought this up?): I think it's a *bad* idea to host Zope 3 on its own site, because: a) It will be yet another systems we need maintainance volunteers for. As it seems we don't even have enough for the current zope.org right now. If we had more volunteers with more time on their hands, they would have already been on the matter and the dog-slow system would have been improved a long time ago (note that I'm not necessarily saying replaced). A zope3.org will eventually need some caching, it will eventually need user management, etc. We already have a human resource problem on the development side, what makes everyone think we won't have it on the maintainance side? A counterargument to this would be that volunteers to maintain the present zope.org infrastructure and content are hard to find. A leaner, meaner, separate zope3.org might find more people that want to be involved. Sorting out the content of zope.org, which has been carried around for more than half a decade, is a job I wouldn't volunteer for. Helping to write some content for a fresh new site and figuring out what fits where is something I *am* volunteering for. b) It is exactly the opposite of what we've been trying to do for the last couple of months: convergence, not divergence! If we want Zope 3 and its Component Architecture to be recognized by people, it needs to be a first class citizen on zope.org, not some separate site. Why? Because Zope 2 will soon incorporate lots of Zope 3 technology (it already does incorporate some), making it all look like two separate worlds is far from reality. As Benji said, we want to market to non-Zope 2 developers with this as well, and we can link zope.org to zope3.org. Placing some distance between Zope 3 and Zope 2 is useful in order to convince people who've been scar(r)ed by their previous Zope 2 experiences, or at least received the meme that Zope 2 is something Python programmers don't want to mix with, to take another look at Zope 3 now. Perhaps we can come up with a similar scenario as what we think is going to happen with Zope 2 and Zope 3. Zope 2 is the old, hard to maintain system here, Zope 3 the new cool system. We intend to improve Zope 2 by adding in Zope 3 pieces, and eventually start replacing parts of it with Zope 3 technology. In the foggy future, Zope 2 and Zope 3 become profiles of the same Zope system, until the differences have gone away. zope3.org could be to zope.org what Zope 3 is to Zope 2. We could cherrypick the content in zope.org that is about Zope 3 and want to have in the new site. Eventually we may start building up a section about Zope 3 in Zope 2 as well on the new zope3.org. Over time, more and more of the useful content gets moved, until finally zope.org and zope3.org are essential the same website about Zope. At some stage we flip a switch and turn zope3.org into zope.org. I have a slight preference for something like zope3.org as compared to zope.org/zope3, as I think that makes the separation a bit clearer. Of course, zope.org/zope3 could be technologically separated from the rest of zope.org too. [snip] The new thing is, that Wikipages should be editable with a WYSIWYG editor after the migration. I hope that there will be an option to choose structured text too. Putting WYSIWYG integration into a list of first-class todo items seems like wrong prioritization to me (I'd rather have a stable backend first), but I'm not going to get into that now. It seems that community input wasn't wanted (and I would love to be proven wrong on that)... I think it's important to try to separate the content production/technology aspect of things, which the sprint apparently focused on from the actual site content aspects. From what I can see, the sprint focused on using Zope 3 technologies to build a Zope 3 site. To use Zope 3 for a Zope 3 site seems a good idea from the marketing perspective already -- we want to demonstrate we can eat our own dogfood. The idea seems to have been to use a wiki for this, something which also has a predecent within the Zope community, as well as in the open source community at large. The whole WYSIWYG HTML-edit wiki thing is a neat idea involving using HTML as the wiki markup language instead of something else. We'll just have to see how that works out. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 11 October 2005 09:36, Jake wrote: Why not spend the time and energy making Zope.org a better place than just moving it off to yet another under-developed and utilized website? zope.org has very different requirements than zope3.org. The reason we want our own system is that we need a collaboration tool that works. So this is the goal of zope3.org? In this case I'm not interested in it as much as I thought. I thought we wanted to present zope 3 well to the outside world. I'm not particularly interested a special site for the Zope 3 proposal wiki. [snip] zope.org will be very heavy. zope3.org will be very light; a simple Wiki-like site that promotes collaboration. Even marketing is out of scope right now. Can you point me to the place where this was decided? Zope 3 is urgently in need of better marketing. Anyway, if this is indeed the plan for zope3.org, I was under a few severe misapprehensions and I hereby de-volunteer. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Reinoud van Leeuwen wrote: On Tue, Oct 11, 2005 at 03:53:23PM +0200, Martijn Faassen wrote: Perhaps we can come up with a similar scenario as what we think is going to happen with Zope 2 and Zope 3. Zope 2 is the old, hard to maintain system here, Zope 3 the new cool system. We intend to improve Zope 2 by adding in Zope 3 pieces, and eventually start replacing parts of it with Zope 3 technology. In the foggy future, Zope 2 and Zope 3 become profiles of the same Zope system, until the differences have gone away. Do you mean that the site should run Zope3? Do mature Z3 applications exist for this? I think a site about Zope 3 should ideally run Zope 3. Since there's indeed not much mature in the way of CMS software for Zope 3, and since I've seen reasonable results reached with wiki software to manage sites about open source projects, I figured using a Z3 wiki to manage the site would be doable. Then again, the sprinters apparently have a quite different idea of what 'zope3.org' will be than myself and some others on the mailing list. Their goal seems to be to replace the component architecture wiki. This is not a very important priority to me; the wiki is only in use by a few core Zope 3 developers and in its present state is an anti-marketing tool. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope3.org terminology
Stephan Richter wrote: On Tuesday 11 October 2005 08:57, Martijn Faassen wrote: As goals for the site, at least the top level of it, I'd suggest marketing, and developer marketing primarily. We need to put across that Zope 3 is powerful, cool, easy, extensible, and built on the vast amount of experience with web application development that we have as the Zope community. Developer marketing also means that we need to demonstrate all the things Zope 3 can do for you, i.e. features. The primary first goal was a collaboration site for us. But I think the goals you listed here should be considered as well. [snip] Anyway, I'm volunteering to help out with the text and basic organization of this site. Great! We have no thought much about structure at all, so if we could start another thread discussing it, that would be great! I personally have no preference. For me the current layout of the Zope 3 developer wiki is 95% to what I want. :-) Okay, there's some confusion about this, and I should've read to this point in the thread before I started replying... I much more interested in Zope 3 (developer-level) marketing than in improving the Zope 3 developer's wiki, and think anything called 'zope3.org' should better have a good top-level set of pages that appeals to a broader audience than Zope 3 core developers. So let's not call the Zope 3 developers wiki 'zope3.org', as this is rather confusing... Let's separate some concepts here: * Zope 3 site: the new Zope 3 website with Zope 3 specific information. This could be hosted under zope3.org but is not a requirement. * dev wiki NG: New Zope 3 developer's wiki. This will be hosted under the Zope 3 site, though I'd recommend strongly against hosting it under zope3.org toplevel as that'd be bad marketing. * Zope 3 information integrated into zope.org. Probably done on a superficial level as it's rather a beast. If Zope 3 site becomes good enough we may turn around and integrate Zope 2 information *there* instead. * Wikification: software to run dev wiki NG but not only that: also to run parts of the Zope 3 website. The idea is we try to use a wiki to run the Zope 3 site, so the wiki software is broader in scop than just for the dev wiki. What happened at the sprint was mostly work on Wikification and dev wiki NG. It was *called* zope3.org but we'll now hopefully consider this a misnomer. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 11 October 2005 12:20, Martijn Faassen wrote: [snip] zope.org will be very heavy. zope3.org will be very light; a simple Wiki-like site that promotes collaboration. Even marketing is out of scope right now. Can you point me to the place where this was decided? Zope 3 is urgently in need of better marketing. Well, Jim and I simply agreed that our communication tools have to improve. Since we cannot easily alter the technology on zope.org, we remembered having zope3.org around to play with. Right, but I also had a chat with Jim about zope3.org at the Plone Conference and it wasn't my impression that it was just about the Zope 3 developer's wiki. Perhaps this was a misunderstanding in our conversation. I think a lot of people on the list (not you specifically) have seen the project too concretely. We have not decided anything, other than an approach we would like to try. It might not work at all. We wanted to keep the goals minimal and to subjects that we understand well; and that is a collaboration tool. There is a lot of room for other experiments, content structure, suggestions, etc. All I suggest is that we try those new tools on the existing Zope 3 dev Wiki pages, since this content has to be available anyhow. Yes, I think calling the whole project zope3.org was a bit of a misnomer which set people to think about things quite different than your intent. That this happens to quite a lot of people is a hint that it might not be an optimal name anyway; people expect to see something else when they go there than that wiki. See my reply in the thread where I try to clean up our terminology. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] test.py renamed
Jim Fulton wrote: A better change would be to arrange for the root directory to be excluded from the Python path. In general, any script we use should, by default, exclude its directory from sys.path. Maybe this only turns up if you have a package layout where the __init__.py is in the same place as the test runner? See also my recent blog posting, which talks about related matters: http://faassen.n--tree.net/blog/view/weblog/2005/10/07/0 Groeten, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] event fired when a principal is created
Jim Fulton wrote: Martijn Faassen wrote: Stephan Richter wrote: On Friday 30 September 2005 04:58, Martijn Faassen wrote: Such an event however does not appear to be fired when an UnauthenticatedPrincipal gets fired. This makes adding groups to such a principal not so easy. I think you are right. Feel free to add this feature. Right, I will tr to look into that in the future. I have a suspicion that the whole zope.app.authentication framework is more complicated than it has to be part due to the requirements of the whole etc/ framework. It's possible that it's too complicated, but I can't see how to blame site-management folders. Okay, I was unclear. I think part of what's wrong is the UI. The authentication story has been written a bit too much towards a UI to configure it. This means that configuring it from Python code is a bit harder than it should be. Anyway, I need to think about it all some more. The whole principal prefix story doesn't make life easier either (both authentication objects as well as authenticator plugins have support for a prefix but to make it all work you can't specify a prefix in both places..confusing). Hm, you should be able to. This was badly broken a few months ago and it was improved, but I never looked at what was done. I guess I'd better do that. Oh, then it might in fact be fixed now -- I am still working against the beta here. Anyway, still trying to convince the thing to swallow IP-based groups.. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] a way to get the client IP address in Zope 3?
Hi there,
There doesn't appear to be a way to get the client's IP address from the
request. Zope 2 has a getClientAddr() on the request object that uses
_client_addr, which gets created like this:
if environ.has_key('REMOTE_ADDR'):
self._client_addr = environ['REMOTE_ADDR']
if (environ.has_key('HTTP_X_FORWARDED_FOR') and
self._client_addr in trusted_proxies):
# REMOTE_ADDR is one of our trusted local proxies. Not
# really very remote at all.
# The proxy can tell us the IP of the real remote client in
# the forwarded-for header
self._client_addr = environ[
'HTTP_X_FORWARDED_FOR'].split(',')[-1].strip()
else:
self._client_addr = ''
# The trusted_proxies configuration setting contains a sequence
# of front-end proxies that are trusted to supply an accurate
# X_FORWARDED_FOR header. If REMOTE_ADDR is one of the values in
# this list and it has set an X_FORWARDED_FOR header, ZPublisher
# copies REMOTE_ADDR into X_FORWARDED_BY, and the last element of
# the X_FORWARDED_FOR list into REMOTE_ADDR. X_FORWARDED_FOR is
# left unchanged. The ZConfig machinery may sets this attribute
# on initialization if any trusted-proxies are defined in the
# configuration file.
trusted_proxies = []
Would it be valuable to have equivalent machinery in Zope 3? I would
like to retrieve the IP address and it'd be nice if it worked with proxies.
Porting this code to Zope 3 sounds possible. Some problems:
* 'HTTP_X_FORWARDED_FOR' is not seen as something that ends up in
environ, as it's not considered to be a valid cgi name by
zope.publisher.browser. Where would it end up? In headers?
* There's no zconf setting in Zope 3 that I'm aware of to configure
trusted_proxies
* there's a comment that cookie data is accessed before environ data.
Does this mean a cookie could be crafted to fake REMOTE_ADDR?
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Steve Alexander wrote: I think so too. But I whould not try to explain a PAU (pluggable authentication utility) without to use the word principal. I think using the words user or participant for a principal in this case is not a good idea. Perhaps the scope of the PUA can be extended to have a plug-in factory for User objects, and to make the current User easily available inside page templates and other presentation code. People who wish to use[1] the PUA would define their own User class, which could be as simple as taking the principal id, but would often be more complex according to the needs of their application. Some abstractions to deal with user objects (which for instance can have an email address to name a common case) in Zope 3 would indeed be useful. I found I had to build my own already. Note that such user objects (or group objects) in applications are frequently content objects and are accessible through content space. I think in Zope 2 terms this entity may be called 'member'... The wrong way to go about this is to store user information somewhere under ++etc++, as that isn't content space in my book and I don't want to expose end users (that need to do user management sometimes) to anything in ++etc++. (it's okay to store low-level user information in ++etc++, as at is now, but no extensible user info with extra information like email addresses, etc, I think). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] hurry library put online
Hi there, I've just put the 'hurry' extension library for Zope 3.1 in the Zope 3 base. For commentary on what it's all about, see my blog entry: http://faassen.n--tree.net/blog/view/weblog/2005/09/09/0 In brief, it contains the higher level query language I talked about before, an advanced file widget, and a workflow engine. Code is here: http://codespeak.net/svn/z3/hurry/trunk/ Have fun! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] hurry extension library for Zope 3.1 put online
Hey Z3ECMers, I've just put the 'hurry' extension library for Zope 3.1 in the Zope 3 base. For commentary on what it's all about, see my blog entry: http://faassen.n--tree.net/blog/view/weblog/2005/09/09/0 In brief, it contains the higher level query language I talked about before, an advanced file widget, and a workflow engine. I imagine the file widget and query language are probably lower level than what the ECM project is all about, though that doesn't make them less useful. The little workflow engine we wrote because we were in a hurry to use one; we're not aiming to compete with full-blown ones that are being worked on. It may be useful for people though in applications that don't need the power a larger workflow system brings, and may this way avoid some of the complexities. Code is here: http://codespeak.net/svn/z3/hurry/trunk/ So as not to spread out discussion over too many forums, I think for now the best forum to discuss the hurry library is zope3-dev. (or zope3-users). Have fun! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] hurry extension library for Zope 3.1 put online
Martijn Faassen wrote: Hey Z3ECMers, [oops, wrong mailing list; will resend. sorry for people seeing this twice] Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] defaultView cannot take class as for
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: While the browser:page directive can take a content class for its 'for' attribute (instead of an interface), the browser:defaultView directive doesn't accept this. I tried changing the interface of the defaultView directive so it also accepts classes, but that by itself does not appear to make it work. This somewhat limits the utility of the ability to pass in classes instead of interfaces to the page directive; the point is to have a shortcut so an interface doesn't always need to be defined. Before I dig deeper, I'd first like to know whether this would indeed be considered to be bug? If so, should I check this into trunk or also the Zope 3.1? The intent was to deprecate the use of the defaultView directive to specify anything but the default view name. This decision was made before we had a deprecation mechanism. The recommended way to create a default view is to create a view named index.html, which can be done with the page directive. Aaah, I didn't realize that. I'll just use that then. Hm, after talking to JW here I'm confused again. (though I think index.html will work in this case). Is the following construction deprecated? defaultView name=foo for=... / If not, then my complaint is that 'for' only accepts interfaces, not classes, while the 'for' for the page directive also accepts classes. So, as far as I understand, I am not trying to use defaultView for anything but specifying the default view name, but for a class, not an interface. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] newer versions of zc.catalog available?
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? regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] defaultView cannot take class as for
Hi there, While the browser:page directive can take a content class for its 'for' attribute (instead of an interface), the browser:defaultView directive doesn't accept this. I tried changing the interface of the defaultView directive so it also accepts classes, but that by itself does not appear to make it work. This somewhat limits the utility of the ability to pass in classes instead of interfaces to the page directive; the point is to have a shortcut so an interface doesn't always need to be defined. Before I dig deeper, I'd first like to know whether this would indeed be considered to be bug? If so, should I check this into trunk or also the Zope 3.1? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] catalog 'all documents' abstraction
Jim Fulton wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? What information? Sorry for being unclear. I meant the information motivating the various things introduced, in particular the extent concept. I.e. textual information with goals and motivations -- the why of extents. Anyway, Gary's been replying to this bit so I'll continue in that area of the thread. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] catalog 'all documents' abstraction
Gary Poster wrote: On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? It should be pointed out initially that the son-of-queued-catalog code doesn't have anything to do with extents. I think Jim wants that factored out when we have time so that can be a mix-and-match capability. I think you are asking about extents themselves, though. Okay, I didn't realize yet glancing at this that this is *also* son-of-queued catalog. Interesting. I'll glance at it some more. :) We had three use cases that led us to extents. First, we wanted several catalogs that only indexed certain different things. This could have been done by subscribers, so this wasn't terribly compelling by itself. Okay, this is clear. It's not that clear to me how to efficiently make a subscriber only handle one object type (I've been using the is this a IFoo? If not, return pattern at the start of subscribers), but that's another discussion. Second, we wanted to transparently support queries that merged results across catalog-like data structures. The catalog defined the items we wanted to search through, while some of the other data structures kept track of a larger set of objects (subsuming the set that the catalog cared about). Sometimes, users could perform a query that didn't actually use any of the catalog's data structures, but that should be filtered by the set of the catalog's objects--its extent. I'm not sure I comprehend the motivations behind this one. Could you elaborate? Third, we wanted to let our indexes data be usable for NOT queries. In order to do that, we needed an IFBTree structure that describes the complete set for a given catalog, so that a contained index can simply (and reasonably efficiently) subtract the query result from the full set. The indexes in zc.catalog also use extents for some other similar tricks. This one's also clear. An extent that accepts all objects would effectively be the data structure you want, as I understand it. I'm not sure -- 'not' is indeed context dependent, so which extent is in use to determine the results of a 'not' operation depends on the query. I think it's okay to ask the users to explicitly specify the extent when they're doing the query, as long as there's an easy way to construct it for the simple cases. It is actually (at least typically for us) different than the intid mapping because there are several classes of things that have intids that are not cataloged. If more than one catalog all index the same objects, I'd first wonder why the indexes were not all in the same catalog; Good question. I think one example of such a scenario is if you wrote a codebase, and I extended this codebase with some adapters which carry around information I also want indexed. I may decide not to introduce new indexes into your catalog but instead produce my own catalog to have the concerns separate from each other. In this case I'd want to do queries over multiple catalogs which index the same objects. I'd second say that yes, they probably could share a filter-less extent. Why filter-less? I mean, wouldn't you want to filter on object type? If we want any of zc.catalog in the Zope core, each component will certainly need a proposal, by the way: we're offering this as code that has helped us out and that we think might help others, either directly or as ideas, so we are not duplicating effort. We're not proclaiming it to necessarily be our next core step. Understood. I'm giving you feedback. :) We (Infrae) are going to put some code online eventually that we produced in the project we're working on, for the same reasons. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] catalog 'all documents' abstraction
Hi there, Now that there's a plain catalog and an extent catalog, and while I was implementing a 'not' operator for a query language, I ran into some missing abstraction that would be convienient; a way to get all the object ids that are indexed, preferably in the form of a IFBTree so I can do fast intersections and the like (which are needed for not, which is an intersection of all object ids with those object ids I don't want). Right now this information is not really available in a standard or a very efficient manner. For the normal catalog you can ask the IIntId utility for all int ids, which is reasonable and should be fairly efficient, though it'd be nice to have something come out in IFBTree form (or perhaps the intid's IOBTree can be intersected with an IFBTree directly? that'd be nice..). I also think however that it's the wrong place the ask for this information, as this doesn't work with the extentcatalog. The catalog itself seems like the wrong place to ask as well however, as things would get hairy in the case of a query over multiple catalogs -- which catalog would be asked for all ids that are indexed? Hm, perhaps this isn't ideal either, as this would get hairy in case of a query that spans multiple catalogs -- which catalog will be asked in that case for a list of all documents? (note that 'not equals' on a FieldIndex can be implemented more efficiently as in this case the index itself can be used as the list of 'all documents') Does anybody have ideas on what the best way to go here would be? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Catalog improvements
Dieter Maurer wrote: Martijn Faassen wrote at 2005-8-25 13:49 +0200: ... AdvancedQuery ... I need to figure out the lazy sorting concept too and how to port it to the Zope 3 catalog... I see elsewhere in the thread you also mention it supports a simple form of joins, which is also very interesting. No, AdvancedQuery does not support joins. But, Python is a very powerful gluing language which allows you to implement simple joins yourself. Okay, I misunderstood then. Of course Python allows one to implement joins oneself. :) I don't think we want everybody to write their own joins, though. It certainly cost me some headscratching thinking about it, especially how to do it efficiently and express it compactly, and it would be good if we could come up with a reasonably efficient solution (using indexes?) in the Zope 3 core. We could even start it out as not being very efficient -- it would already be useful to have an abstraction present and we can always make it more efficient in the future. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] file objects and formlib
Hi there, I just saw this being changed in the wiki (by Fred Drake): the new zope.formlib. - -- Reimplement file objects (for Zope 2 or Zope 3 to take advantage of the new 'zope.formlib' I'm curious to hear what this is about. I've been dealing with file widgets in particular a lot recently and have some input on it: File widgets as in Zope 3 don't behave like text widgets. Basically they don't behave like any other widgets at all; they're an odd duck out. This is bad, because: - for an add form, if something goes wrong and the form is redisplayed with some validation errors, the uploaded file information is lost. This is bad because for a required file field, it requires multiple uploads where one should suffice, and for a non-required file field, it's even worse, as a user would have no motivation to re-upload the same file after validation failure and redisplay of the form, resulting in no file being uploaded at all. - for an edit form, there is no resubmit of the same data as you'd see with a text widget where the data hasn't been changed by the user. Instead there's either no upload, or an upload of a new file. This behavior is again different than a text widget, which makes programming harder as the programmer will have to check 'is there a file already there?' manually in some cases. I've already solved the validation feedback form problem by storing files in a session temporarily. This isn't efficient, but I *also* developed something that will lick that problem and that I'll present in a lightning talk at the Plone conference. I'm working on solving the second problem, so that a file is *always* present in the validated form data no matter whether it only ever resided on the server in case of an edit form. Basically I emulate the behavior of the text widget, for the file widget. This way they become a lot easier to work with. I'll happily share all that I have, and this mail is just to prevent work is inadvertently duplicated. Probably you meant to work on something else, but I figured I'd make sure. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Florent's O-R blog entry
Paul Winkler wrote:
Martijn Faassen wrote:
Missing powerful query concepts
---
Certain powerful query concepts like joins, available in a relational
setting, are missing. I've already run into a scenario where I wanted to
someting like this: given a bunch of version objects with field 'id',
where multiple objects can have the same 'id' to indicate they're
versions of the same object, I want all objects where field
'workflow_state' is 'PUBLISHED' unless there is another object with the
same id that have workflow_state 'NEW', in which case I want that one'.
I think joins would be a way to solve it, though I haven't figured out
the details, nor how to implement them efficiently on top of the
catalog. This kind of thing is where a relational database makes life a
lot simpler.
I used to have the same complaints in Zope 2, but so far I've been happy
with Dieter's AdvancedQuery product. See
http://www.dieter.handshake.de/pyprojects/zope/AdvancedQuery.html
It might be worth a look while thinking about what to implement for zope 3.
Here's Dieter's example from that page:
from Products.AdvancedQuery import Eq, Between, Le
# search for objects below 'a/b/c' with ids between 'a' and 'z~'
query = Eq('path','a/b/c') Between('id', 'a', 'z~')
Something very similar to this I can also do with the layer I built on
top of Zope 3's catalog. It wasn't hard to write at all, which speaks
for the clean design of the Zope 3 catalog.
# evaluate and sort descending by 'modified' and ascending by 'Creator'
context.Catalog.evalAdvancedQuery(query, (('modified','desc'), 'Creator',))
This is interesting and my layer cannot do this yet.
# search 'News' not yet archived and 'File's not yet expired.
now = context.ZopeTime()
query = Eq('portal_type', 'News') ~ Le('ArchivalDate', now)
| Eq('portal_type', 'File') ~ Le('expires', now)
context.Catalog.evalAdvancedQuery(query)
In your example you haven't done a join as I describe above, unless I
miss something. The essential part is that I want an object with state
'PUBLISHED' unless there is another object where field 'ID' is the same
as this object that is with state 'NEW'. The join is in the 'ID'
matching part.
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security frustrations
Benji York wrote: Martijn Faassen wrote: * after object creation but before the object is added, various things are done to the object. * authorization error: user cannot access various attributes. If these things are done by subscribers, would using trusted subscribers help? I guess it could; I've used a trusted adapter in a few places to get around security concerns. However, not everything is done by subscribers. I have a little workflow system that in some cases can create new versions of objects, for instance. My frustration is more that one has to do *something* special than that there aren't any solutions. Knowing to use trusted subscribers and having to design ones application around them would be another thing one would need to know to 'please' the security system. I know of course that security is hard, so maybe there's no way than to just bite the bullet... But it still leaves me wishing; it's rather easy to break the security of an application. Perhaps I'm wishing for a system where a lot more can be made trusted easily. As far as I understand right now it's possible with adapters, and apparently subscribers (I didn't know this, so I may be missing more). Perhaps the answer is different altogether. And again, perhaps it's just going to be either hard or insecure, pick one. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: security frustrations
Florent Guillaume wrote: Does it work to just set __parent__ to the container? Or does the zopesecuritypolicy require more accurate context? I think that might work, though I've had previous problems with actually being allowed to *set* the __parent__ to the container. :) I would also be worried about code that checks whether an object has a previous parent and sends a different event (move). Given that, it's easier to just removeSecurityProxy on the code.. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AdapterLookup C optimizations 'timeit' benchmarks
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 05 August 2005 09:46, Benji York wrote: By my estimations(i hope i'm not wrong :) C version gives ~20-26% speed up for different methods. Running the functional tests for a Zope 3 based systems with 434 tests yielded (best of 3) a time of 1:12.51 for the trunk and 1:12.32 for the branch. That's about a 0.25 percent improvement. That's a bad argument. Several projects only use zope.interface and its adapter registry (for example twisted). For them a 20-26% improvement for the adapter lookup would be significant. Just because other parts of Zope 3 are even slower and use more time than the adapter lookup, it does not have to mean that this is a bad/insufficient improvement. The tradeoff is complexity / loss of maintainability vs. speedup. If Benji's measurements hold up, we would be taking on the burden of maintaining a parallel C implementation (in sync with the canonical C version) within our project, for the (possible) benefit to other projects. I also hope that in this case (unlike some other cases in the Zope 3 source code), a parallel Python version *will* be maintained and continue to be tested. I ran into some problem with non-functioning stuff (debugging logs) in the security implementation, most likely because of a C implementation getting hooked in after the original code was written (compounded by there being no tests to verify whether the security logging facility worked). The big question is of course what the impact on the performance of a typical Zope 3 application will be. If it's minimal it's not really worth it. Note that projects like PyPy are getting there slowly but steadily -- it's possible that in a year's time we may only need to do minimal tweaking of Python code to benefit from compilation-level benefits. In the mean time, Pyrex is another avenue that might be worthwhile exploring. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] problems with ZOPE_WATCH_CHECKERS
Hi there, I'm trying to debug the security of a Zope 3 application (in Zope 3.1 beta) and I am having trouble getting ZOPE_WATCH_CHECKERS to work. If I set it to 1, I expect to see information on which attributes on which object are denied. I however see nothing whatever. If I set it to a higher value, I *do* see a few granted messages, though suspiciously few messages appear and rather confusing ones, especially as I am trying to a access a page that doesn't tie into the ZMI: [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442764ec [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442a17ec [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442ef5ec What's going on? Why do the only messages I ever see involve ContextHelpView? Is it possible that this mechanism is broken? Some debugging did seem to indicate the right logging checkers get created, but perhaps the logging methods do not actually get called most of the time? In an attempt at deeper debugging I tried removing the C implementation (_zope_security_checker.so) temporarily, as the checker.py code seems to indicate it should fallback on the Python version. Unfortunately, Zope 3 fails to start in this case... Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Updating the docutils package
Martijn Pieters wrote: I'd like to update the horribly outdated version of docutils in the Zope3 tree (version 0.3.0) to the latest resease (version 0.3.9). +1 Regards, Another Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] actions and subclasses in zc.page
Martijn Faassen wrote: Hi there, I noticed another possible oddness with zc.page. [snip description] Just pinging this thread; I'd still like to know whether this behavior is considered a bug, and if so, how to go about fixing it. If not, is there some way to accomplish what I want. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] small problem in zc.page?
Fred Drake wrote: On 7/7/05, Martijn Faassen [EMAIL PROTECTED] wrote: I hope that moving it into the zope package doesn't mean it will be only maintained for Zope 3.2 (as it requires python 2.4). While I obviously don't expect it to be released with Zope 3.1 I hope we can pull a release of it that can be installed into Zope 3.1 (as long as it's running Python 2.4). Our current plan is to keep it as a separate top-level project in Subversion, and link it into Zope 3 using svn:externals (similar to zope.testing). Sounds good. I am looking forward to being able to help out zc.page's further development (though so far I only ran into relatively minor snags). Note that zc.page does contain a (very small) quantity of ZCML and that zope traditionally doesn't contain ZCML; what's the thinking about that? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: interaction between LocationProxy and IIntId utility
Tres Seaver wrote: [snip] I find the same pattern creeping into my work: content objects need to be policy free, which means that they can't do things like emit events, because whether and when to emit them is policy. For instance, if your content objects have setter methods (or properties as sugar on top of them), such methods can't know whether they are the only / last one to be called for a given interaction, and therefore whether they can safely / efficiently emit a modified event. Hm. Having to separate out policy such as event sending out from the content object does make it harder to start out with just a few classes of mostly Python code (that do not care too much about the framework yet) and then refactor them into more components later when the time is there. I like being able to start out with relatively few entities in the beginning and being able to wait and see where the pieces make most sense later on. I imagine this is also a pattern many beginners would start out with; after all rich classes are the pattern in Zope 3. While such classes do not care a lot about the framework yet it'd be nice to allow them to send events and so on. Anyway, I'll just have to gain some more experience building Zope 3 applications to see whether this is a real problem or not. Likewise, content objects don't seem (to me, anyway) to know enough to handle their own renaming; rather, such handling needs to occur in conjunction with the container (and perhaps the ContainerProxy that wraps them). Though it's fairly easy to make content objects in charge of their own naming by letting them implement INameChooser (they do often have to discuss things with their container to see whether the generated name already exists, though). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] possible bug in catalog code
Hi there, in zope.app.catalog.attribute, there's the following functionality: def index_doc(self, docid, object): if self.interface is not None: object = self.interface(object, None) if object is None: return None value = getattr(object, self.field_name, None) if value is None: return None if self.field_callable: try: value = value() except: return None return super(AttributeIndex, self).index_doc(docid, value) The following sequence I think leads to trouble: value = getattr(object, self.field_name, None) if value is None: return None as this means attributes that do exist and have the value None would never be indexed (as index_doc() is never reached). Instead, I'd suggest the following code: try: value = getattr(object, self.field_name) except AttributeError: return None or alternatively if for some reason getattr() with a default is preferred (though I suspect the exception approach is slightly faster): # module level NotFound = object() value = getattr(object, self.field_name, NotFound) if value is NotFound: return None If this is indeed decided to be a bug, is it okay if I check in a fix for this? I'll try to devise a test of course. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] interaction between LocationProxy and IIntId utility
Hi there, We just noticed that some objects were not being cataloged correctly. After a lot of debugging, we noticed the following: The IntId utility wouldn't find the unique id for an object when a modified event was sent. As a result, it wasn't being indexed. We figured out that there was an odd difference between the object that came into the IntId utility (through a modification event) and the object that we could take from the folder: the one taken directly from the folder has a __name__ and __parent__. Even though the memory address looked the same when using repr(), they were not identical. As a result the int id couldn't be found. Finally with some help from Stephan Richter giving us the clue that this __name__ and __parent__ information could only be lost if LocationProxy is in play, we figured out what what we think is going on: What is stored in the ZODB are LocationProxy wrapped objects. The location proxy wrappers get a unique id reference in the IntId utility, not the objects themselves. Now when you send an ObjectModificationEvent from one the document's *own methods*, the event is sent with as payload to catalog something that is not proxy wrapped. This means that the int id can never be found for this object, and thus the reindexing cannot take place properly. This basically means that LocationProxy wrapped objects cannot reliably respond correctly to ObjectModificationEvents, and thus won't be cataloged correctly. If the ObjectModifiedEvent is sent by methods inside the object itself, things will fail, if the ObjectModifiedEvent is sent by code elsewhere, they'll likely work. This is all fixed by subclassing Contained, but the catalog not working reliably for LocationProxy wrapped objects sounds scary. You could do something with the IntId utility automatically un-location-proxy-wrapping the objects if necessary, but that would mean that what is stored wouldn't know its location anymore, which would also be bad. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] small problem in zc.page?
Jim Fulton wrote: Martijn Faassen wrote: Christian Theune wrote: [snip] I'm actually interested in what the plans/needs for zc.page are to move into core. Maybe I/we can spend some time on bug fixing ... Even if not in the core, it'd already help if this wasn't a one-time snapshot but a SVN repository where we can check in. I wanted to get it into better shape before moving it to the Zope repository, but that is looking silly. I'll try to find time to move it this weekend. Thanks! This raises the question of what it should be called. I'm thinking it should move to the zope package, but page seems a tad too general a name. Thoughts? No ideas on a better name right now. I hope that moving it into the zope package doesn't mean it will be only maintained for Zope 3.2 (as it requires python 2.4). While I obviously don't expect it to be released with Zope 3.1 I hope we can pull a release of it that can be installed into Zope 3.1 (as long as it's running Python 2.4). In that sense it being a separate package outside of Zope 3 may actually make things slightly easier for now, though I won't argue this too strenuously. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] setSite() and functional tests
Hi there, I'm using zope.app.testing.functional.FunctionalTestCase to write functional, Python-level tests for a Zope 3 application, and I just ran into something that might or might not be a bug. When the application code tested changed the site using setSite(), the next test will still run in the context of the old site. After some puzzling I determined that placing setSite(None) in the tearDown() method fixed these issues. Perhaps this is something that can be placed in FunctionalTestCase's teardown itself, though? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] status of zc.page?
Hi there, Since we keep running into snags and frustrations with the zope.app.form package, we're checking out zc.page and see whether it could help us any. We're going to try using it today. We have some concerns though: * the snapshot is probably aging as bugs get discovered and fixed in your repository. Could you perhaps update the snapshot? * it requires Python 2.4.1. Zope 3.1 to my knowledge is targetting Python 2.3. It looks like it's fairly easy to rewrite the few decorators that are in the package itself so they work with Python 2.3 instead, but we don't want to maintain our own fork. Obviously we want to use this with Zope 3.1. Am I mistaken about the Python version targetted by Zope 3.1? I'm rather confused that you're apparently using Python 2.4.1 for internal Zope 3 projects. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Interviews with people involved in Zope 3 projects
Stephan Richter wrote: [snip] Then there are of course various Five-based projects, but I am not familiar with them. Can anyone enlighten me here? Also, if I forgot any project, please tell me about it! It does not have to be a commercial product either! Concerning Five projects, one project that was announced is CPSSharedCalendar, which is a Nuxeo project (that can however also work in straight Zope + Five, besides the CPS support). Infrae has also worked on that. Nuxeo also has a mail project based on Five. There are also a few Silva projects that use Five, but most have not been released yet. The one that has been released is SilvaFlexibleXML. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/app/broken/broken.pt Fixed a typo.
Benji York wrote: Gintautas Miliauskas wrote: Log message for revision 30377: Fixed a typo. -pThis probably because the class' module, +pThis probably because the class module, I don't think the apostrophe was misplaced, but there should probably be an is in there. How about this: pThis is probably because the class' module, Completely without context, so I may be wrong, but module of the class sounds better then. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] lxml / elementtre inclusion
Jim Fulton wrote: Julien Anguenot wrote: Can we consider the inclusion of lxml or elementtre within the Zope3 core ? Absolutely. Cool! Are the repective licenses, BSD and MIT-like an issue ? Absolutely. :) I would prefer that we include lxml and that it be ZPL. That is, my hope is that Martijn can release lxml under ZPL as well as any other licenses he wishes. It needn't be copyright ZC and Contributors. It could be copyright Infrae. Well, libxml2/libxslt cannot be relicensed by me, so the MIT license will stay. If it helps to also license lxml under the ZPL besides the existing BSD license, that shouldn't be an issue, though I myself do not comprehend why adversiting-clause-less BSD should be an issue; as far as I understood it could be safely combined with absolutely anything. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Five 1.0 released!
Five 1.0 released! == The Five team is happy to release Five 1.0. Five is a Zope 2 product that allows you to integrate Zope 3 technologies into Zope 2, today. There are no big feature additions compared to Five 0.3, but does include significant bugfixes, along with some minor tweaks. We went directly to 1.0 as we feel that Five is production-ready software. Five 1.0 works with Zope 2.7. The big news is that we also plan to include Five 1.0 in Zope 2.8, so that you can use Zope 3 technology in Zope 2.8 out of the box. Much work to enable this was done at the Paris Zope 3/Five sprint organized by Nuxeo. This release therefore also contains the changes made to integrate Five into Zope 2.8 done at the Paris Zope 3/Five sprint, but works with Zope 2.7. Consult the CHANGES_ for more details. .. _CHANGES: http://codespeak.net/z3/five/CHANGES.html Five right now allows you to use the following Zope 3 technologies in Zope 2: * Zope 3 interfaces * adapters * pages (views), including skins, layers and resources * edit and add forms, based on schemas * ZCML We've tried to keep the Five experience as close to Zope 3 as possible, so this means that what you learn while using Five should also be applicable to Zope 3. Five 1.0 is being used in production-grade projects, among others at Nuxeo_ and Infrae_. .. _Nuxeo: http://www.nuxeo.com .. _Infrae: http://www.infrae.com Five 1.0 can be downloaded here: http://codespeak.net/z3/five/release/Five-1.0.tgz More information about Five can be found on our website, here: http://codespeak.net/z3/five/ We hope you'll join our mailing list and let hear from yourself! About the Zope 3 Base - Five is part of the *Zope 3 Base* project, which aims to offer an approachable area for developers of Zope 3 related software. More about the Zope 3 base and its projects can be found here: http://codespeak.net/z3/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Building standalone ZPT from Zope 3 using zpkgtools
Shane Hathaway wrote: [snip] I'm sure Fred is doing excellent work, but I'm having trouble seeing why we need zpkgtools. Is it not sufficient to just python setup.py install all of Zope 3? I've been doing that with Zope 3 Subversion checkouts and Twisted, even though I actually use less than 10% of the code installed. In fact, my co-workers are about to put such a system into production. The unused code causes no problems that I've detected. I think one of the main reasons for zpkgtools is indeed to allow a release of part of the repository, such as just the page template engine, but as you say, in the context of Five I've definitely found it a lot easier to just tell people to use the whole of Zope 3, as that is already released by another party. I also think it easier to have the release and repository be very similar. I'm not convinced myself that this weighs up against the reasons not to invent a zope3 specific packaging system; there are a few drawbacks currently: * it's unique to Zope 3 and ZODB. Nobody else is using it. Is the Zope 3 project in the business of building package tools, or do we not have enough difficulty on our hands just building Zope 3? * apparently, as seen on the ZODB list, the packaging format currently used makes life harder for downstream packages such as debian. * it doesn't tackle some use cases. I'm not sure it could help integration of Zope 3 into Zope 2.8, for instance; a svn:external seemed to make more sense. I think the first point is the most important worry; we're doing something nobody else is doing in an area outside Zope's core purpose, which is to be a web application service. This stands apart from the quality and merit the tool and its ideas certainly have. I just do not think it a good idea if the Zope project ends up having to maintain *and* explain this indefinitely. I hope, and trust this is the intention, that efforts can be undertaken to make the packaging tool used outside of the Zope project, preferably a Python standard. Of course you still run the significant risk it will never be accepted as such. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Building standalone ZPT from Zope 3 using zpkgtools
Stephan Richter wrote: [snip] I think of zpkgtools as a prototype for extensions that are necessary for distutils. Is it the Zope project's job to extend distutils, though? I mean, developing something new is nice, but there's a lot of a new stuff on our plate already, isn't there? Overall, I think that zpkgtools is very successful. And it is not Zope-specific! Twisted could use it too. It's Zope specific as only the Zope projects are using it, as far as I am aware. Lots of people could use it, but I'm worried that without significant effort to promote and adjust this, it won't happen. I mean, Twisted could use ZCML too, but they're not, and I doubt they're likely to, and they're the most likely project to use ZCML of them all, as they use zope.interface already. Granted zpkgtools is easier to distribute independently, but then again, for distributing ZCML we have zpktgtools. :) Perhaps I'm wrong and zpkgtools takes time out of our hands overall already, including maintenance and learning curve. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release numbering
Jim Fulton wrote: Martijn Faassen wrote: [snip] [snip] I've always said that we will provide support for transitioning to Zope 3, being careful to say transition support rather than backward compatibility. And that's not what the Zope X3 release notes strongly imply, which is again, my point. The message has been received differently than you said it, and we're still sending out messages with bear very different interpretation. It's not a secret that many have been skeptical about backwards compatibility with Zope 2, but there's a reason for why we thought this was the plan. Let's go back to 2001 to a message by Shane Hathaway, which certainly looked official enough to me at the time (it was in response to an 'open letter'): http://mail.zope.org/pipermail/zope-dev/2001-December/014313.html Q: What is Zope 3X? A: Zope 3X is Zope rebuilt from the ground up, applying the lessons learned from Zope 2 and CMF. Q: What is Zope 3? A: Zope 3 is Zope 3X plus compatibility with Zope 2 products. Q: Will Zope 3X be compatible with Zope 2 products? A: No. Q: Will Zope 3 be compatible with Zope 2 products? A: Yes. Q: Will Zope 3X support DTML? A: Probably not. Q: Will Zope 3 support DTML? A: Yes. Q: Will Zope 3X be compatible with CMF? A: No. Q: Will Zope 3 be compatible with CMF? A: Very likely, but a lot of the CMF ideas will be folded directly into Zope 3. You might not need CMF anymore. This is what settled in our mind as the plan. It may be where Stephan got this idea. It is still interfering with the message coming from Zope Corporation that it appears did undergo some shifts over time. [snip] We better have some clearer communication on this topic between Zope 3 core developers, Sorry, my mind control skills are lacking. ;) I thought we could communicate using natural languages and all that. :) I can't tell Stephan what to think. I guess I'd prefer that he support the party line, but heck, who said there was a party. Well, Stephan probably thought he *was* supporting the party line, which is why I'm suggesting you two have a little chat about this. as Stephan himself seems to distinguish between a still official public plan and his doubts it will be like that. At least, this is what I conclude from this statement earlier in this discussion: Yup. I wish he wouldn't say things like this, especially as the release manager. He got the idea somewhere, and I doubt this is his own official plan. This is why I'm trying to bring this issue out into the open. [snip] I greatly appreciate the assistence you and others have provided in helping to bring some of the benefits of Zope 3 to Zope 2. Thank you, and I understand this. My criticisms are perhaps annoying but intended to improve the process. [snip] Sorry, I can't figure out which this you mean in your sentance above. I didn't think I said this. Stephan said the following in the Zope X3 release notes: The X in the name stands for experimental, since this release not try to provide any backward-compatibility to Zope 2. [snip] The problem is that I can't predict the future. Maybe you think you can. I know Stephan does. ;) I think I can make educated guesses about the future, just like everybody else. [snip] Anyway, my message here is to get a bit clearer on the message. I've clearly gained a very different idea about what the X means than you do, and that's not for lack of observing the Zope 3 process. Let's get our marketing straightened out. I certainly want to be clear about what I say. The bottom line though is that we don't know. We will continue to support Zope 2 at least until we do know how the transition will work. [snip evolutionary scenario] That's an interesting scenario. In some ways Five is already starting to be like this, though full compatibility is still far off. Anyway, I think the best way to communicate this is not to explain it (as it is complicated), and not to give the impression we will get backwards compatibility, and not to detract from Zope 3 by adding in Xs that we may not drop for years (as this evolution will take years) and will have to explain all that time. After all, we said it meant experimental in 2004, and look how long it is to get rid of the message of 2001 about backwards compatibility -- 4 years later we're still not clear about it. You can make the dropping of the X a positive marketing event: It is in our opinion that Zope 3.1 is more than ready for production use, which is why we decided to drop the X for experimental. We will also continue to work on making the transition between Zope 2 and Zope 3 as smooth as possible. As a first step, Zope 2.8 includes Zope 3 features in the form of Five. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release numbering
Martijn Faassen wrote: [snip] This is what settled in our mind as the plan. It may be where Stephan got this idea. It is still interfering with the message coming from Zope Corporation that it appears did undergo some shifts over time. Whoah, that last sentence makes no sense, I mean something like: It is still interfering with the message coming from Zope Corporation, which does appear to have undergone some shifts over time. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Hey, I think the most sane would be: Zope 2.8 - Zope 2.9 - Zope 2.x, for however many iterations it's necessary. Zope 2 will grow some Zope 3 forward compatibility with Five, but this depends on Five contributors. Right now, we're doing fairly well and we hope this keeps up. Zope X3.0 - Zope 3.1 - Zope 3.2 and so on, until we feel we want to declare a Zope 4.0. If you want to drop the X after 3.1 that's fine too, but I don't see a reason not to drop it now. The whole X3-3.0 is rather bizarre and confuses -- X3 is not a release name but a product name, but we have no real plans for a non-X 3 anyway..., but the mythical Zope 3 proper *is* the reason for having the 3 duplicated, as far as I can see. You need to communicate that the strategy changed, and that we won't have a Zope 3 ever that will offer Zope 2 backwards compatibility. We may want to supply some of that, but that should be a separate project, with its own release numbers. I'll call that project Six for now, as that's 2 times 3. :) It's probably better to correct this impression now than to wait indefinitely as: * people can prepare their migration strategy better, either by porting to Zope 3 straight or porting to Five first, and then later to Zope 3. Nobody will be waiting for magical components which will be offered by Six then, as that's complete vaporware now; there are no resources for it, nobody seems to really want to do it, etc. * we can drop the X and have a more sensible release naming pattern for Zope 3. * we have at least another strategy now and can point people to Five/Zope 2.8. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope3-dev Digest, Vol 21, Issue 29
Paul Winkler wrote: [snip] Something looking like Nevow maybe? Its template language looks kind of like ZPT without all the fancy TALES expressions. I'll also take a look at the Nevow to see whether we can get any ideas about a Clarity frontend. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
