AW: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
Hi Lennart -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Lennart Regebro [...] Again, these lists are about the development of, not development with. Can you explain why do you think this makes a difference? Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
Hi Lennart Betreff: Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists [...] Can you explain why do you think this makes a difference? Because developing WITH Zope2 and Zope 3 are very different. The development OF Zope 2 and Zope 3 are not, sincem as mentioned, the development OF Zope 2 is almost exclusively about getting more Zope 3 into Zope 2. The differences in community that is taken as a reason for keeping the lists separate simply do not exist anymore. There are no separate Zope 2 developers anymore. Ah, now I see your point. My motivation not to merge the dev lists is another one. I think many developer (500 subscribers) which develops with Zope 3 watches the Zope3-dev list and if they have questions, they will ask them on the zope3-users list. Hm, I think your mail also means, we can't avoid to have Zope 2 topics on the zope3-dev list because Zope 2 is going to move to Zope 3 and we have to exchange information. Doesn't matter how the list is called. Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Philipp Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a use it all or nothing concept? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Hi Martijn Betreff: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3 [...] Grok *aims* to support reusing bits of it. It hasn't reached this goal yet as we focused on making it work first, but has been an explicit seocndary goal from the beginning last year. We need to do some things to make this possible: * Done: Grok's mechanism of scanning for classes and instances in modules and issuing some form of configuration has been factored out into the martian library. * as Philipp mentioned, emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. * related to this, Grok turns off some of Zope 3's security infrastructure (for content objects, not for views). The Grok core should continue doing this for the forseeable future, but of course if you want to reuse other bits of Grok standalone this shouldn't come along. So, this is slowly but surely coming nearer. We want Grok to be a unified story for most users, so this is not our *primary* goal, but we do want Grok's work to be reusable in other Zope 3 projects as well. Cool, sounds promising Regards Roger Ineichen Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Zope 3 releases?
Hi Tres Cc: zope3-dev Development Betreff: [Zope3-dev] Re: Zope 3 releases? [...] A frozen release would consist of: - A single, frozen KGS (index pages cannot change after release). Can we use a flag on the server side e.g. in the index page, so nobody is able to upload files if we use automated tools for the upload? Or can we use a different url which we can't upload after the freeze has be done. Like we do in subversion at least in some svn clients there will be a not if you try to commit to a url which contains the /tag/ part. [...] I would note that the script I posted a week or so ago for building package index pages from a directory full of source distributions would be a perfectly adequate tool for constructing such a KGS: simple copy or link all the frozen distributions into a directory and run the script. Once you've verified that the installation regime works from the generated files, you *never touch them again*. Do you think the directory should be a subversion tag which makes it reproducable? [...] Roger Ineichen Tres. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Hi Andreas What do you man by two development paradigms? Please don't build a wall between Zope 2 and Zope 3 developers. Most old-school Zope 2 developers are doing development also with Zope 3 components and Zope 3 techniques. Look at Plone 3.0 and its heavy usage of Zope 3 techniques...impressing. The Zope 3 development paradigms are highly accepted by most Zope 2 core developers...we are all sitting in the same boat. There is a fundamental difference in the Zope 2 and Zope 3 architecture but little difference between the paradigms how we should design and write software on top of the Zope platform in the future. The distinction between Zope 2 and Zope 3 must disappear. We must speak of Zope. Everything else is counterproductive when it comes to promoting Zope. There is only one Zope developer community and most of us have a Zope 2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial separation between Zope 2 and Zope 3 developers is undesirable in my opinion. You are using 7 times the term Zope2 and 9 times Zope 3 and also Plone 3.0 in this small text. Can you try to describe this without 2 or 3 in Zope *? I guess not, right? I really don't care about how it is called, but I'm sure we need some naming convention and since we have one, I don't see any reason to change this. You also use the term Plone 3.0 which you implie that we know that you mean the Plone which uses Zope 3 components. You are respecting the postifx 3.0 in the Plone world but not for Zope? why? I'm a little confused and don't understand why you are lobbing for such a renaming and at the same time you are using this terms so heavy. Regards Roger Ineichen Andreas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Zope 3 releases?
Hi Jim An: zope3-dev Development Betreff: [Zope3-dev] Zope 3 releases? [...] - We need to decide what a Zope 3 release is (or maybe multiple flavors). I favor copying the linux experiences, but have an open mind. I think there are two different point of views. Zope as a library and Zope as a product. I think you are asking for Zope 3 as a component library. As a developer I'm happy with this kind of library and don't need a Zope 3 application server release. But I also see another point of view. Zope 3 as a product we can lobby for and a application server which is ready to use with a easy setup. e.g. windows installer or buildout, easy install. I think such a Zope 3 application server has the following benefit. - easy to install and ready to use for newbees or small projects - a proof that we are able to setup such a working server - a working setup which 3rd party developer can develop with - a product which the sales can show and lobby for But who will do this? Probably we need a own community which picks up this task and supports a Zope application server built with cool zope components out there. I guess we will see some different Releases in the near future based on zope components e.g. - Grok - Z3C - Plone 3.0 What do you think is somebody interested in doing another release based on zope components? And if so, does this make a Zope 3 release obsolate? Regards Roger Ineichen Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Betreff: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. -1 Not that I'm not interested in what's going on in Zope 2, but the two list let me easy separate this two different topics. And it will allow me to read the Zope2 mails in digest mode if I don't have time to read all. Another reason for not to switch is the mailinglist observation in the different web apps out there. They are very usefull. btw, a cool app, this is another reason to keep the trunk up and running. I guess they checkout our code and count the lines ;-). See: http://www.ohloh.net/projects/4495?p=Zope+3 e.g. Codebase 97,598 LOC Effort (est.) 25 Person Years Project Cost $1,348,258 Regards Roger Ineichen Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: Are pagelets content providers?
Hi Thomas Betreff: [Zope3-dev] Re: AW: Are pagelets content providers? Roger Ineichen wrote: I was carfully skip some additional method decalration because I didn't know if we gona use IPagelets without render and update in other implementations. The z3c.pagelet README.txt says that Pagelets are views which can be called and support the update and render pattern. So either this refers to the particular implementation only, in which case I'd say an independent definition of the concept of pagelets is missing, or otherwise it doesn't leave much room for implementations without update and render methods. Probably we should say; Pagelets are views which support the publisher __call__ attribute and provide the update/render pattern. I disagree, the IPagelet is not a IContentProvider. The pagelet is the component which defines the content and the renderer is the content provider. It's a delegation pattern. I explicit didn't implement IContentProvider in IPagelet because a pagelet has to conceptual functionality of a page and not of a content provider or viewlet thing. So the pagelet is really two things: a specific implementation of a browser page, and a component which defines content. Both should reflect in its interface, and why should something which defines content and follows the update/render pattern not formally be declared a content provider? Calling it something else with the same methods serves only to keep around an interface twice, by different names. You are wrong here. A IContentProvider doesn't define content. A IContentProvider provides content. That's different. I a component defines content it provides the IPresentation interface which is the case for IPagelet. A IContentProvider knows only how to get content for another component. Again, it's a delegation pattern. AFAICS, there's nothing wrong with two content providers taking part in delivering the pagelet's content: one that originally creates the content behind the scenes, and one that is called from the layout template and delegates content creation to the former. You don't have to prohibit a pagelet to be called a content provider in order not to call it from the template directly. The issue might just be about interfaces describing how an object can be used instead of what code is supposed to use it. You are saying, that we have IContentProvider providing content and defining content. Define content is the part of the IPresentation interface. OTOH, there's real value in pagelets being content providers: library or application developers wouldn't have to decide up front whether their content providing component is to be used for primary or supplementary page content by deciding whether to implement it as a pagelet or a content provider; it could be both without adding any dead chicken abstractions. A real-world use case is z3c.form forms: they are implemented as pagelets which is fine as long as each form makes up a page of its own. However, we'd like to combine forms with other stuff, such as a search form with a result list. This is possible by using a form (a pagelet) as a content provider, but that feels like a hack as long as it isn't backed by formal interfaces. Probably I don't understand this correct. Are you thinking about a IContentProvider which collects more then one pagelet? Probably I don't see your idea. Can you descibe it what do you mean with as long as ... page of its own and pagelet as content provider. I don't understand how a pagelet can get called as a content provider. The adaption doesn't work because they support different __init__ method signatures. The interface IPagelet(IBrowserPage) should reflect the page replacement. The IPageletRenderer(IContentProvider) should describe the pattern how the pagelet content get accessed. Dou you see my idea behind this declarations? I do, but I can't follow the conclusion that pagelets should not at the same time be declared content providers, which they de facto are. What do you think, should we add render/update to the IPagelet which is not defined in IBrowserPage? Or should we add a IRenderUpdate interface in zope.? which we can use in zope.formlib, z3c.form, z3c.pagelet and probably many more interfaces? Having thought some more about it since asking it as a question yesterday, I now definitely think that IPagelet should extend both IBrowserPage and IContentProvider. I can't see any value in a new IRenderUpdate interface since the distinction from IContentProvider would be very academic IMO. Did you recognize that the __init__ are different. A IContentProvider defines: def __init__(self, context, request, view) self.context = context self.request = request self.view = view and a IPagelet defines: def __init__(self, context, request): self.context = context
AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
Hi Lennart Betreff: [Zope3-dev] zope.app.securitypolicy deferred imports errors. Roger Inechens split of zope.app.securitypolicy into zope.securitypolicy cause loads of problems, because many of the deferred imports were incorrect. I saw Stefan Richter fixed some, and I have fixed some more. Yes you are right First somebody that can make releases (which may or may not include me, I honestly don't know who can make releases of eggs) needs to make a new one. But we also need to avoid this stuff in the future. Yes, we always have to avoid errors, but sometimes it happens. And since we dont test against the trunk, we don't see this kind of errors anymore. This means we test against custom projects. I didn't fully recognize this and was trusting the tests. But I was wrong. We don't have tests for this anymore. We probably didn't have test for my error at all. In other words; Right now we only test if a egg works within their dependency. But we don't test other eggs if they work with the egg we develop. See all my different mails about this topic! How is the recommended process to solve this? Some sort of unittest to make sure the deferred impoirt work? Is there an example of this somewhere? I'm proposing to test against a set of possible breaking stuff. This means we need a kind of zope3 trunk egg which our test will deoend on. See the mails form Stpehan Richter about that. Jim also agrees on that but is thinking this should be optional as far as I understand the mails between Stephan and Jim. We defently lost the overall tests we had in the trunk setup. And this is a very bad idea. If we don't recommend to run all tests again form a single egg refactoring, we will see more errors like this. Some of us are thinking about to automate this tests with buildbot. But this tests will only test released packages which is also bad. I think the only way to automate such tests can be supported by a staging server. I personaly think, less test -- more errors. Even if we try hard to avoid errors during development. Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] Re: AW: Are pagelets content providers?
Hi Jacob, Thomas Betreff: Re: AW: [Zope3-dev] Re: AW: Are pagelets content providers? Hi Roger, I didn't follow this discussion closely but thought this needed a comment. Roger Ineichen wrote: [snip lots of context...] Did you recognize that the __init__ are different. A IContentProvider defines: def __init__(self, context, request, view) self.context = context self.request = request self.view = view and a IPagelet defines: def __init__(self, context, request): self.context = context self.request = request Probably we should describe this in the interface too. This whould manifest the difference of content provider which provide content and pagelets whcih defines content in a better way. It would make sense to have the 'view' attribute a part of the IContentProvider interface, and *that* might make them different. The constructor signature is all about the class instead of the instance and should therefore *not* be part of the interface. It is perfectly reasonable to have a number of different (multi-)adapters with different signatures that adapt to the same interface. Hope this makes sense. I'll go back to lurking now. Yes you are right, that was the reason I didn't define the __init__ method in the interface. But I still think a IPagelet isn't a IContentProvider by default. Of corse another class can be defined as IContentProvider and IPagelet. Such a class whould then provide a different __init__ method then the pagelet does right now. Thomas; Should we implement a z3c.form/z3c.pagelet package? There we could support z3c.form base classes built up on pagelets. Probably called z3c.formpagelet which contains IPageletForm, IPageletAddForm etc. Regards Roger Ineichen Regards Jacob -- Jacob Holm CTO Improva ApS ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: AW: Re: AW: Are pagelets content providers?
Hi Thomas Betreff: [Zope3-dev] Re: AW: AW: Re: AW: Are pagelets content providers? Roger Ineichen wrote: Yes you are right, that was the reason I didn't define the __init__ method in the interface. But I still think a IPagelet isn't a IContentProvider by default. Of corse another class can be defined as IContentProvider and IPagelet. Such a class whould then provide a different __init__ method then the pagelet does right now. See my other response I wrote before I read this message of yours. As longer as I think about your idea, you are probably right. I agree with not declaring __init__ in the interface. That's what we did. The only concren I have right now with IPagelet is inherited from IContentProvider is the default TALES expression which uses the following code for lookup IContentProvider: class TALESProviderExpression(expressions.StringExpr): ... # Try to look up the provider. provider = zope.component.queryMultiAdapter( (context, request, view), interfaces.IContentProvider, name) ... This requieres a specific __init__ method. What do you recommend to do? I'm open to improve it but how can we reflect the different adaption concepts like we have with the different __init__ used by IPagelet and IContentProvider. I agree that __init__ is not a part of the interface. But I also think it should be a part of a (probably another) interface since this is required by a specific lookup pattern. But that's probably over designed. Any idea? Should we implement a z3c.form/z3c.pagelet package? There we could support z3c.form base classes built up on pagelets. Probably called z3c.formpagelet which contains IPageletForm, IPageletAddForm etc. This would solve my use case but sounds like a lot of architecture, to be honest. I think this is exactly what I hoped to avoid by pinning the internal communication between pagelets and pagelet renderers down to talking IContentProvider and thereby allowing pagelets to be used as content providers from everywhere. See the dead chicken remark in my first reply to you. Ok, I see your idea Regards Roger Ineichen -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
Hi Jim, Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors. [...] Yes, please do. It's up to people making changes to use some judgement. I mentioned in that thread that when I make changes to core components, I often do test against the old trunk tree. Despite all of your complaints about the need to do this, you didn't. That's not true. I did test the package against the trunk. But the problem was, I also adjusted the imports in the packages. What I was missing is to run the tests against a older version of the trunk. [...] Most people aren't changing these components. Nevertheless, we still have the old tree available for testing. We didn't lose anything. I can agree with, we didn't loose anything. So let's say it's not just there anymore. And this is a very bad idea. If we don't recommend to run all tests again form a single egg refactoring, we will see more errors like this. Don't you think it's a little hypocritical bemoaning that we're not doing this when you don't do it yourself? Again, I did run the tests against the runk, but I didn't recognize that I should test my changes against a older version of packages. Probably I'm not that smart to take care on everything and was trusting on testing to much ;-) I know there is no difference between the old trunk and the new egg development testing. This error whould also happen to me if I where doing it in the old trunk setup. My problem was not test my work against a older version of the trunk. Or like Lennart told, the missing tests for integration (import changes). I personaly think, less test -- more errors. So test! What's stopping you? The old tree is still available! The crapy do it by your self test setup is stopping me really hard or at least slowing me down right now more then the it should. It's not easy to follow all the ideas behind egg, setuptools, easy_install, buildout in such a speed like we changed to this patterns. I agree Speed kills, but I think switch to eggs force us to take it all or nothing. Regards Roger Ineichen [...] Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] major packaging reorganization happening in 3.4releases?
Hi all Betreff: Re: [Zope3-dev] major packaging reorganization happening in 3.4releases? On 02.10.2007, at 14:25, Jim Fulton wrote: On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote: Hi there, Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! Sorry, I can't resist to answer the question with some black humor: I don't know, probably ask the release manager. Ah, right, we do not have a releas manager anymore since all developer have to release their eggs by itself. I think this question/answer describes our problem very well we have now. Again, don't take it personal! I'm not pointing with my finger to anybody. I just point my finger on the situation we have right now. Agreed. Someone needs to sloow down. Speed kills. deserves to be added to the Zen of Python. (Actually, ZoP does have a variation of that.) +100. that was the most unproductive week in lovely systems HQ ever. I agree, but that's another topic... ...and probably I'm the person to blame. But what does slowdown mean? Do we need to slowdown the development or do we have to slowdown releasing eggs? Or both? Or do we need to slow down till we have a better development process or tools? If so, can we make progress on that? Regards Roger Ineichen jodok Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Beautiful is better than ugly. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Are pagelets content providers?
Hi Thomas Betreff: [Zope3-dev] Are pagelets content providers? During the gocept sprint on z3c.form last week we found that the interface of pagelets (z3c.pagelet.interfaces.IPagelet) is a mere marker interface on top of IBrowserPage, which seems to me a bit thin. Yes and no ;-) I was carfully skip some additional method decalration because I didn't know if we gona use IPagelets without render and update in other implementations. For one, the implementation of pagelets makes use of the render and update methods. Since these methods are the ones to be customized when writing custom pagelets, they should be documented. Yes you are probably right, feel free to add them to the IPagelet interface. I didn't use the IPagelet interface without render/update till now and I see no other usecase without them. Or does anybody see such non render/update usecase for IPagelet? While it would be easy enough to just add the methods to IPagelet (which has actually been done for render by now), I think IPagelet should really be an extension to zope.contentprovider.interfaces.IContentProvider in addition to IBrowserPage. It is already possible to use pagelets such as z3c.form.form.Form as content providers. While the pagelet implementation distinguishes between pagelet and pagelet renderer, only the latter being declared the content provider, this distinction seems to be made only in order for the content provider lookup to return the same pagelet instance that is the view. The renderer then only (sort of) forwards the pagelet's own content provider functionality, so the pagelet might as well be declared a content provider itself. I disagree, the IPagelet is not a IContentProvider. The pagelet is the component which defines the content and the renderer is the content provider. It's a delegation pattern. I explicit didn't implement IContentProvider in IPagelet because a pagelet has to conceptual functionality of a page and not of a content provider or viewlet thing. Hm, probably the naming of the pagelet within it's (*let) in the name is not so good as I was thinking. It could suggest that the pagelet is a additional page content like viewlets or content providers. But a pagelet is a full replacement for the IBrowserPage and not additional. The interface IPagelet(IBrowserPage) should reflect the page replacement. The IPageletRenderer(IContentProvider) should describe the pattern how the pagelet content get accessed. Dou you see my idea behind this declarations? What do you think, should we add render/update to the IPagelet which is not defined in IBrowserPage? Or should we add a IRenderUpdate interface in zope.? which we can use in zope.formlib, z3c.form, z3c.pagelet and probably many more interfaces? Regards Roger Ineichen Any thoughts, objections, ideas? -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Benji Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. I mean, we don't use all zope packages in our test dependency if we develop eggs. What was the reason to use a subset of of zope packages for egg testing? e.g. extras_require = dict( test = [ 'zope.testbrowser', 'zope.app.securitypolicy', 'some more zope.* packages but why not all zope.*' ], ), Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. I see btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? It doesn't do much of value at all right now. The transition to individual projects per package has left it behind. There are good ideas to make the buildbot work with the new setup, now we need someone to implement them. Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. e.g. python test.py -s zope -pv could be now in a egg: bin\test -s zope -pv This whould allow us to run all zope.* tests during egg development. Regards Roger Ineichen -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? [...] So what do people think about a pretty comprehensive Zope 3 meta egg for testing purposes? +1 Tests are written for using and not ignoring them. Otherwise it means we deploy eggs wich are not tested against all zope.* packages which is a very bad idea. Regards Roger Ineichen Regards, Stephan ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Benji Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing? [...] Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? That's the point which I don't understand that nobody is seeing: Not my egg depends on other packages. Other package depend on the egg I develop. And tests are there for ensure that other eggs will work with my work on a specific egg. Tests are a setup of tools which can ensure that my changes are compatible with existing things. Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. This whould allow us to run all zope.* tests during egg development. It sounds like it would build the equivalent of the old-style Zope 3 trunk for each and every zope.* buildout. That sounds awful. Perhaps I'm misunderstanding your proposal. All zope.* tests together are a way to ensure compatibility. I doesn't make sense to me not participate with all tests before a single egg get deployed. Not running all test in a namespace like we have with the zope package namspace, sounds to me that a package which doesn't like to agree on all tests should get move to another namesapce. Regards Roger Ineichen -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] Why do we restrict our egg testing?
Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing? On 9/27/07, Benji York [EMAIL PROTECTED] wrote: Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? I suspect there are hidden differences in expectations here. ;-) Roger, when you assemble an application, are you expecting to find all of zope.* in the result? No I excpect some of them, but others excpect others. So I'm pretty shure if we count all different setup then we can excpect all packages in the summary. We're not expecting that in the projects I'm involved in. In fact, I'd be pretty upset to find a lot of that stuff in there, and would like to see less of it than I do. That's the problem you only solve your problems with this pattern. but the zope namspace suggest participation. And you can't ensure quality wiht this point of view. Zope 3 is not an application, and I consider that a good thing. I agree, Zope 3 is not a application, but packages in this namespace can break things outside of your context. That doesn't matter if this are packages in a 3rd party namespace, but this should not happen in the zope namespace. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Why do we restrict our egg testing?
Hi Tres Betreff: [Zope3-dev] Re: Why do we restrict our egg testing? [...] I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. Yes, I was one of the folks proposing to take more care on separating things. And I'm also proposing running all tests for a single package in a namesapce which the package is using before deployment. I think testing is overall a quality management aspect. Let me explain quality management in a abstract context. If you have a house and the target is that arround your house the tings must be clean and arrangend. You will define soemthing like: All things arround my house have to be clean and not dirty. This quality management rule will work. If you define many different things like; My carpet in front of my hous door must be clean. This whould not work. Because why, if somebody takes the carpet and brings it to a cleaning company, probably the floor under the missing carpet is dirty then. And this does not fit with your overall quality target. This is similar to our testing concept. Using small test setups for single eggs without to focus on zope as a monolitic thing will fail. Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Why do we restrict our egg testing?
Hi Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? Is this a bad idea? Did I miss something? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Proposal, free views
Heads up, Please review this proposal. I'll implement it shortly if nobody has objections. We need it for our work here at the Foliage sprint. If you have objections, please tell me what you think is not well done and tell me your ideas to solve the problem in another way. http://wiki.zope.org/zope3/FreeViews btw, the proposed implementation does not affect existing projects and their setup. It also does not affect egg based projects. It only offers us a additional hook which allows us to load component configuration from packages without the built in views. Thanks Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Proposal, free views
Hi Lennart Cc: Adam Groszer; zope3-dev@zope.org; [EMAIL PROTECTED] Betreff: Re: [Zope3-dev] Proposal, free views On 9/23/07, Roger Ineichen [EMAIL PROTECTED] wrote: Heads up, Please review this proposal. OK. I have to admit that I don't fully understand it. This proposal describes a way to make the usage of such built in views optional. Such built in views means what? Optional how? And why? I mean with built in views just views which comes within a package. Such view component are located in the browser folder and built on the BrowserPage classes. I guess the term views is common for that and should be well known. The additional component.zcml could be used to include only component related configuration whitout the view parts defined in the browser.zcml. Because the browser.zcml get's included from the configure.zcml but not from the component.zcml OK, I understand what you want to do: Start the practice of having views in one zcml and components in another, so you can include only the component one if so desired. I don't understand why, though. Right now it's not possible to use another layout pattern without to support zmi_views and zmi_action and it's menut item pattern. The views defined in all packages also require the use-macro, fill-slot pattern which is not what we allways whant. Right now there is no option to get rid of this patterns except to duplicate packages and replace existing views. That's what you will have to do anyway. Because if you don't include the views, you will have to replace them in another package. And you can override them in another package already... Yes, this is what we like to do. We like to write 3rd party packages. But the problem is, this views are using templates which we don't support, e.g. use-macro, fill-slot etc. Also the configure.zcml file registers menu items for zmi_views and zmi_action which is does not exist in our setup. I guess it should be possible to use Zope3 without the need of zmi_views and zmi_action menu items Whih is not the case right now. See all the ftesting.zcml files in the different egg packages. Pobabbly the proposal should be simpler and propose. Get rid of zmi_views, zmi_actions, StandardMacros and hardcoded template relations in views Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Proposal, free views
Hi Martin Betreff: [Zope3-dev] Re: Proposal, free views Roger Ineichen wrote: Heads up, Please review this proposal. I'll implement it shortly if nobody has objections. We need it for our work here at the Foliage sprint. If you have objections, please tell me what you think is not well done and tell me your ideas to solve the problem in another way. http://wiki.zope.org/zope3/FreeViews I read this, but I still don't understand what you're proposing. Is this about moving component registrations around in the standard Zope 3 packages, or are we talking about new functionality here? The technical part of the proposal describes to move the content of the configure.zcml to a component.zcml file. And include the component.zcml from the configure.zcml. This whould allow us to use only the component.zcml The configure.zcml whould also include the browser.zcml or the configure.zcml form the browser package. If sombody uses configure.zcml nothing changes. Regards Roger Ineichen Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] AW: Proposal, free views
Hi Philip Betreff: Re: Proposal, free views Roger Ineichen wrote: Please review this proposal. I'll implement it shortly if nobody has objections. We need it for our work here at the Foliage sprint. If you have objections, please tell me what you think is not well done and tell me your ideas to solve the problem in another way. http://wiki.zope.org/zope3/FreeViews I don't understand the name of this proposal. In fact, I have no idea what it's supposed to mean. I think the proposal should've been named something like Conventions for splitting up component and view registrations I didn't find a better name 5 o'clock in the morning. It's related to the movie free willy ;-) (Btw, the reST formatting is messed up). btw, the proposed implementation does not affect existing projects and their setup. It also does not affect egg based projects. It only offers us a additional hook which allows us to load component configuration from packages without the built in views. In the proposal you write: Views or let's say browser pages and it's derivates are based on a specific layout pattern. The default views are using macros and slots. This is not allways what we like to use. This proposal describes a way to make the usage of such built in views optional. I understand the motivation. But I don't agree with the solution. I've you're not ok with the existing views, then you currently have two options * Simply *ignore* that they exist. Zope actually has facilities for doing this on a technical basis. Simply don't inherit your skin from IDefaultBrowserLayer, and voila, you won't get any pre-configured views at all. I can't have unused code in our codebase. We have swiss banks as customers and can't pass their security assesment with such a setup. Belive me, it's not easy to fit their needs. * If you're interested in replacing a few select views with your own implementations, you can use ZCML overrides. Or use layers (which is a similar solution to the previous one). Same here, we can't have unused code in our codebase. This will increase the security assesment and I don't like to write more documentation for them. That said, I do wish there was a way to specifically disable ZCML directives. We've been talking about this for a long time, actually. I think the biggest use case is for disabling event handlers. But naturally it could be used to disable other things, too. I agree, +1 anytime if you propose such a solution. So, if the two options I gave above won't work for you, I think we should rather look into making it possible to disable certain ZCML directives, or even disable the execution of certain ZCML files altogether. I think we will split packages in its base parts. For exapmle this means we will create a package zope.session that contains the python api and degrade zope.app.session to contain the zmi views. My reservations toward to proposal aside, you also write: But if we like to load only the component related configuration without any view configuration, we could use include component=foo.bar / Why do we need to change ZCML? Isn't include package=foo.bar file=component.zcml / sufficient? Let's not make ZCML any more complicated or magical that it already is. Magic? The directive is well define with a interface IInclude ;-) Regards Roger Ineichen -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] AW: AW: Proposal, free views
Hi Philipp Betreff: Re: AW: Proposal, free views Roger Ineichen wrote: This proposal describes a way to make the usage of such built in views optional. Such built in views means what? Optional how? And why? I mean with built in views just views which comes within a package. Such view component are located in the browser folder and built on the BrowserPage classes. I guess the term views is common for that and should be well known. Yes, but the overall language of the proposal is very confusing. Sorry. But it just is. It starts with the title which I coudln't make sense of at all. And the introduction is just as confusing. Yes, it is, and this was the idea to get people reading it. But probably this was not such a good idea. The additional component.zcml could be used to include only component related configuration whitout the view parts defined in the browser.zcml. Because the browser.zcml get's included from the configure.zcml but not from the component.zcml OK, I understand what you want to do: Start the practice of having views in one zcml and components in another, so you can include only the component one if so desired. I don't understand why, though. Right now it's not possible to use another layout pattern without to support zmi_views and zmi_action and it's menut item pattern. The views defined in all packages also require the use-macro, fill-slot pattern which is not what we allways whant. Right now there is no option to get rid of this patterns except to duplicate packages and replace existing views. That's what you will have to do anyway. Because if you don't include the views, you will have to replace them in another package. And you can override them in another package already... Yes, this is what we like to do. We like to write 3rd party packages. But the problem is, this views are using templates which we don't support, e.g. use-macro, fill-slot etc. Also the configure.zcml file registers menu items for zmi_views and zmi_action which is does not exist in our setup. So what? Will it hurt you to configure those zmi_* menus, even if they won't be used? Will it hurt you having those views around, even if you won't be using them? Yes it hurts and it hurts realy hard. And even if you don't care about them at all, you can still make sure you don't inherit your skin from IDefaultBrowserLayer. Then you will never ever get those views. I guess it should be possible to use Zope3 without the need of zmi_views and zmi_action menu items Maybe. You still haven't said why it is so important to you. Your guess ist right, we can't have unused code in our codebase. zmi_views, zmi_actions, zope.app.form, and all zmi views are impossible to have in our codebase. Also, the whole menus thing is a new aspect. The proposal mentions it, but from what I understood, it doesn't define it as a problem. You might want to revise your proposal to include this aspect if it's important to you. Whih is not the case right now. See all the ftesting.zcml files in the different egg packages. I don't see anything about zmi_* menus in ftesting.zcml files. All I see is the inclusion of zope.app.zcmlfiles which loads all the stuff a typical Zope 3 application needs (including the zmi_* menus). No comment I think the problem with the zmi_* menus is a differnt one. Currently, all packages simply seem to assume that all their dependencies are being loaded anyway. Let's take the zmi_* menu thing as an example. Every package that configures views for any of the zmi_* menus depends on the menus being configured. Such a package should really say: include package=zope.app.zcmlfiles file=menus.zcml / at the top of its configuration. Likewise, a component that depends on the annotation adapters to work should load zope.annotation's configuration at the beginning of its configuration, and so on. We're not doing this right now. If we did, a lot of things would actually get much simpler for egg-based projects. I agree, but how? I've made this one of the sprint tasks for the NeckarSprint: http://wiki.zope.org/zope3/NeckarSprint2007. Pobabbly the proposal should be simpler and propose. Get rid of zmi_views, zmi_actions, StandardMacros and hardcoded template relations in views As said, it seems that the proposal text could really use some refinements regarding your actual problems and your actual goals. Feel free to change it, any improvment is welcome! Regards Roger Ineichen -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: Proposal, free views
Hi Martin Betreff: [Zope3-dev] Re: AW: Proposal, free views Roger Ineichen wrote: * Simply *ignore* that they exist. Zope actually has facilities for doing this on a technical basis. Simply don't inherit your skin from IDefaultBrowserLayer, and voila, you won't get any pre-configured views at all. I can't have unused code in our codebase. We have swiss banks as customers and can't pass their security assesment with such a setup. Belive me, it's not easy to fit their needs. * If you're interested in replacing a few select views with your own implementations, you can use ZCML overrides. Or use layers (which is a similar solution to the previous one). Same here, we can't have unused code in our codebase. This will increase the security assesment and I don't like to write more documentation for them. I assume you mean you can't have any unused component active/registered. The code is still going to be there, unless you fork Zope 3 and remove the files you don't need, in which case this proposal isn't going to help you much anyway. You are right, it's a way to do it but it doesn't solve all our problems. The prefered option whould be not have this code in our codebase. Which means we have to split it in different packages. Another option whould be the proposed solution which brings us the possibility not register/activate them. I think it makes sense to introduce a pattern that makes it easier choose which components you need. However, if I understand you correctly (and I second Philipp here - the proposal is confusing as it's worded now), you're talking about refactoring the ZCML of every package that uses browser components. I understand there's full backwards compatibility (via includes into the root configure.zcml), but it's still a slightly risky and time-consuming dance. I agree Regards Roger Ineichen Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Christian Betreff: [Zope3-dev] Re: skin support for xmlrpc On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said: On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote: If you register views for a base request type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? If I understand the concept correct. This is a builtin backdoor. Doesn't this allow to bypass the Apache rewrite rule? With: http://www.foobar.com/++api++xmlrpc/doSomething If the rewrite rule in Apache is: RewriteRule (/?.*) http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1 [P,L] Or does the ++api++ namespace recognize the skin? Which means the url rewritten url is. With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething But then, do we need to regsiter the ++api++ for each layer? I guess this is not what you are asking for. right? My main issue on this thread is allways the same: Skins are a security layer. And don't bypass them, then this let us use views which we don't like to provide in a layer/skin. I really don't understand this thread. Does nobody take care on default traversal APIs? I'm really confused now. Probably I don't see soemthing or understand it not correctly. Do you understand what I mean this this backdoor use case? Or I'm totaly wrong? Regards Roger Ineichen -- Christian Zagrodnick gocept gmbh co. kg . forsterstrasse 29 . 06112 halle/saale www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Cristian Betreff: Re: [Zope3-dev] Re: skin support for xmlrpc [...] The problem is simple, XML-RPC has used the IBrowserRequest and now it uses the IXMLRPCRequest. This is why the XML-RPC views in different projects don't work anymore. This means the XML-RPC uses a browser request which is bad because it enables the views everywhere. No no. XML-RPC did use IXMLRPCRequest before. All I added was the IXMLRPCSkinType which did not exist. What I also changed is the ++skin++ traverser which was registered for * instead of IBrowserRequest. But I consider the old behaviour a bug since skins were only valid with IBrowserRequest. Ah, sorry, I was wrong then. But we still need the option to register XML-RPC views for explicit request types. The solution is to provide the request interface which was the default before the changes. But don't take the option way to use other request interface then the default for registration. I'll need it. Because I'll take care on security and don't like to register everything on whatever. Before I'll revert the layer-support will be there in a third party package, probably using ++api++. The only thing what I need is a directive which allows me to register XML-RPC views on a explicit skin type then. Then this will avoid to get XML-RPC views for all browser request types. right? I'll work at the same topic to at the sprint and implement this option for the zif.jsonserver. Right now the zif.jsonserver depends on the xmlrpc metaconfigure directive. If this your changes will fit, I can still depend on this. Thanks for taking care on this issue. Regards Roger Ineichen -- Christian Zagrodnick gocept gmbh co. kg . forsterstrasse 29 . 06112 halle/saale www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Fred Betreff: Re: [Zope3-dev] Re: skin support for xmlrpc [...] Can't say I've ever advocated removing that, but I'm one of those skin-means-request-type folks. If you register views for a base request type, you probably will open a backdor in other projects. Because if someone uses such a package which has views regsitered for a conatext and standard request type this views are available in every instance which the discriminator will fit. Layers - skins or the z3c.baseregsitry are concepts for avoid this. Regards Roger Ineichen I suspect the hangup some people have is really about the skin name for something that's not about browser presentation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Betreff: [Zope3-dev] Re: skin support for xmlrpc On 13.09.2007, at 17:28, Philipp von Weitershausen wrote: Christian Theune wrote: Let me propose a change: 1. We revert the change. Any news on this? Yes. Over the last few days I pondered about how to do it without xmlrpc layers. But there doesn't seem to be a way nice and easy way. So I will need to implement the layer support in a different package. The revert will be done till monday, maybe already tomorrow. Sorry for the delay. Anyway, could somebody who had an error with that tell me what the problem was? I just heard we had a problem. Why revert? We need layers in every kind of context, request adapter registration because it's the concept which permission get registered in different projects on a single server sharing packages. The problem is simple, XML-RPC has used the IBrowserRequest and now it uses the IXMLRPCRequest. This is why the XML-RPC views in different projects don't work anymore. This means the XML-RPC uses a browser request which is bad because it enables the views everywhere. The solution is to provide the request interface which was the default before the changes. But don't take the option way to use other request interface then the default for registration. I'll need it. Because I'll take care on security and don't like to register everything on whatever. Regards Roger Ineichen -- Christian Zagrodnick gocept gmbh co. kg . forsterstrasse 29 . 06112 halle/saale www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] skin support for xmlrpc
Hi Stephan Cc: 'Philipp von Weitershausen'; [EMAIL PROTECTED]; 'Christian Zagrodnick'; zope3-dev@zope.org Betreff: Re: AW: [Zope3-dev] skin support for xmlrpc [...] Since the skin directive is gone layer also support the skinning concept. But the main reason of layers is still offering a security namespace. I disagree. I have *never* thought of it as a security namespace. I think of it as a *user interface* functionality namespace. Doens't matter if you thougt about of it or not. But it is ;-) Skins are a base concept for security if it comes to rewrite rules in Apache. The usage of ++skin++A, ++skin++B let us map domains to request layers. And if we do this right, it let use enable skin A for applicaiton A and restrict using skin A on applicaiton B. Skins e.g. layers which views are registered for are a security layer. The neat thing about skins is that different skins can provide different HTML. But thats the nature of a skin and has nothing to do why the views support a layer attribute. Since we use PageTemplate file in views it let us think that layers are there for change the template or since z3c.pagelets it let us change the layout at all on a view base. But this is just a neat sideeffect of the layer concept. btw, this is also true for z3c.form. The layer attribute let us register a specific IWidget with different permission in one skin then in another skin. It also let us register another template for both skin. this are tow different concepts. That's the reason why I implemented z3c.pagelet. This package let us separate the security layer used for views and the UI layer used for templates. Then both registration concept are based on the layer attribute. [...] seccurity issue --- Let's say you have a app offering a XML-RPC server shutdown view. You whould do the following: 1. regsiter a public and a private skin 2. register the XML-RPC view to the layer used by the private skin 3. Run Zope at port 8080 blocked form outside by firewall 4. Use Apache rewrite rules and point to the public and private skin e.g. private.foo.com and public.foo.com 5. Use a rewrite rule and point to the private skin restricting access to a internal network or some IP addresses. How whould you restrict access from the public skin to the XML-RPC view without layer support used in step 2? The solution is pretty straight forward using a pluggable traverser. After all, pluggable traversers were designed to be maximally flexible and to allow all possibilities, which includes simulating skins, if you want. I don't say it's not possible to secure XML-RPC views with a additional concept e.g. z3c.traverser. Right now we can't take care on security wihtout any a additional concept for XML-RPC views. Layers are the missing feature. That's just bad. Because the available permission attribte sugests to secure them. The real issue here is well known and is called backdoor. Secure views is also hugh and well known problem in the AJAX world which the missing layer in XML-RPC view belongs to. this is also true for JSON views which are based on the XML-RPC implementation. Probably I don't speak about the same use case like Christian had if he started this tread. I just say that security requires a request layer in XML-RPC views. Remember, all what I saying is a problem if it comes to the virtual host supported by the Apache rewrite or proxy usage. Then a XML-RPC without a layer will become available in the wrong domain e.g. in every domain. btw, a z3c.traverser whould have to check for a specific skin in it's request for apply another layer which enables the XML-RPC view. Without a skin layer it's not possible that the traverse acts as a XML-RPC view enabler because the traverser doesn't know if you are calling skin A or skin B. You can say that the traverser is only available on skin A, but then again, you need a layer/skin for that. Regards Roger Ineichen Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi stephan Cc: Christian Zagrodnick Betreff: Re: [Zope3-dev] Re: skin support for xmlrpc [...] The idea is now to register list_foo for different layers/skins/api-sets. This could also be achieved by creating dummy model-objects and/or traversers, but would be much less understandable. What essentially happens is that the views are registered for different request types. You can solve this issue easily using pluggable traversers. There is absolutely no need to use skins here. For example, a traverser plugin can simply mark the request with a directly provided interface and return the same object. This would work very much like a skin without mis-using the concept. That's wrong, even pluggable traverser using skins if you use Apache and virtual hosts. Without a skin you can't handle that. this means a pluggable traverse is just a additinal hook the solve a simple problem. [...] Then use a custom traverser, please!? :-) eek, I don't like them. And I see no reason to use pluggable traverser for every JSON or XML-RPC view which should not get shared in different skins. Not a skin is a DNS - layout mapping lookup from the Apache point of view. It probably would not be much of a problem to remove the skin things again and put it directly to the project or another third-party component. But it doesn't feel right. Please revert the skin support again. This is a pretty major change and I gave a -1 on the original discussion already. There was never a full proposal either. But It's a security issue not having layer support in views even XML-RPC views behave exactly like ever other view handled by browser - apache - server. Regards Roger Ineichen Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Jodok Cc: Christian Zagrodnick; zope3-dev@zope.org Betreff: Re: [Zope3-dev] Re: skin support for xmlrpc [...] for me xmlrpc is remote procedure call. a rpc has a signature and always the same result. and as stephan said - traversers should help here. Yes, but what does this mean? Where is the difference to any other view e.g. BrowserRequest views. XML-RPC views are exactly the same as any other multi adapter which can get traversed. All of them need to support a layer. Except that the default layer for XML-RPC is the XMLRPC request and not the DefaultBrowserRequest. Traverser are not needed for this. That's a totaly different concept. btw, the layer is a namespace for permission settings and not skinning/layout in this usecase. [...] Regards Roger Ineichen _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] skin support for xmlrpc
Hi all Cc: Christian Zagrodnick Betreff: Re: [Zope3-dev] skin support for xmlrpc On Monday 27 August 2007 16:11, Christian Theune wrote: 1. We revert the change. 2. We create a new traverser with a different namespace that implements our intended behaviour. Two options after that: 3a. We supply this traverser by default, or 3b. We ship it in a separate package. +1 with option 3b. BTW, you should have a look at z3c.traverser, which +allows you to not use namespaces at all anymore. eek, I don't like to think about that. No, no, no... just wait, Christian is defently right to add layer for XML-RPC views. Are you all sure you understand the need of a layer in every kind of request? It's about permission registration and not skinning. Since the skin directive is gone layer also support the skinning concept. But the main reason of layers is still offering a security namespace. In short skin support in xmlrpc -- No layer support in xmlrpc -- Yes it's a security issue! Layers allow us to use different security registrations for the same view in different projects. seccurity issue --- Let's say you have a app offering a XML-RPC server shutdown view. You whould do the following: 1. regsiter a public and a private skin 2. register the XML-RPC view to the layer used by the private skin 3. Run Zope at port 8080 blocked form outside by firewall 4. Use Apache rewrite rules and point to the public and private skin e.g. private.foo.com and public.foo.com 5. Use a rewrite rule and point to the private skin restricting access to a internal network or some IP addresses. How whould you restrict access from the public skin to the XML-RPC view without layer support used in step 2? Hm, nobody seeing this let me think that I'm wrong. But I'm pretty sure that I'm right. or not? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] skin support for xmlrpc
Cc: zope3-dev zope3-dev Betreff: [Zope3-dev] skin support for xmlrpc hi christian, it seems like your recent changes to support skins in xmlrpc views introduced some troubles. we spent several hours to debug not working xmlrpc views and finally found that nailing the zope.traversing egg to 3.4.x resolved the troubles. while looking at your changes we were wondering why you want to support skins in xmlrpc views? for me, a xmlrpc call is a remote procedure call and has to do nothing with skins. it's not yellow, pink or orange and has no templates associated. can you explain your use-case for this? Jodok, a skin e.g. a layer in a view, even XML-RPC is a security thing not a layout thing. Every traversable adapter needs it's own posibility to register security for it. This is only possible if we have the request available in the discriminator. It's also needed if you setup tow different projects on one server and like to register a XML-RPC view for e.g. ISite in one project and not for the ISite in the other project. If this both sites using a own layer, it's possible ot register the XML-RPC view only for one project. The other option doing this wihtout having a layer in the XML-RPC directive is to use the baseregistry. But why does this break soemthing? Was the initial request interface the BrowserRequest and now it uses by default the IDefaultBrowserLayer? This whould be bad. Using the IBrowserRequest as default layer whould be the best choice. It whouldn't break anything and allows to register views only with your specific request/interface. Regards Roger Ineichen _ END OF MESSAGE thanks jodok -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: SVN: zope.location/trunk/s - moved IPossibleSite and ISite from zope.app.component to zope.location
Hi -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Philipp von Weitershausen Gesendet: Mittwoch, 22. August 2007 15:37 An: Thomas Lotze [...] This is an interesting move. I can settle with the idea, but I wonder this was discussed... Last time I remember we were discussing the idea of a package a la zope.site or zope.componentsite... (Also, as long as we're moving things, I wouldn't mind renaming ISite to IComponentSite). -1 Renaming doesn't make sense to me since in every book and documentation ISite is used. I'm against every beautification which has no benefit. IPossibleSite -- ISite makes perfect sense to me. IPossibleSite -- IComponentSite doesnt make sense to me. and IPossibleComponentSite -- IComponentSite is worth to comment on. Regards Roger Ineichen _ END OF MESSAGE -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: relying on win32api in windows supportofzc.zope3recipes
Hi Martijn Betreff: Re: [Zope3-dev] Re: AW: relying on win32api in windows supportofzc.zope3recipes [...] We're just talking about Zope here, and installing Zope into its own buildout (possibly sharing eggs with another). This means we don't care much about installing the documentation anyway, just having the libraries importable so that Zope can do its work on windows. Yes, but that's exactly the problem with the buildout process. The installation process right now with buildout is not able to deal with anything which is not a egg and it's horrible if it comes to 3rd party python library weher no eggs are available. At least on windows. I think we should support recipe for (exe, msi) installers and other things like (zip) unzipper etc. Right now it's a nightmare to use buildout if it comes to e.g. pysqlite. [...] Regards Roger Ineichen Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] relying on win32api in windows support ofzc.zope3recipes
Hi Martijn Betreff: [Zope3-dev] relying on win32api in windows support ofzc.zope3recipes Hi there, I'm trying on zc.zope3recipes on Windows. I notice that some of the tests rely on a module called win32api, which I assume is in the Win32 extensions that I haven't installed in my windows Python yet. Do we have to have win32api installed to make this work, or is it possible to lift this requirement? Was the original way to run Zope 3 trunk dependent on win32api? I guess, but I'm not sure; Python 2.5 includes ctypes which could be used as a replacement for the win32 part. To some previous questions in this thread. I'm fine with any improvements and doctest cleanup. My problem was, that I couldn't really merge the linux tests into one document because I didn't had a linux box when I wrote the implementation for testing. I agree with the maintainance overhead. That's bad. I also recognized the buildout difference in the tests. I guess the egg version is older then the version then I used from the trunk. I guess again, I think Jim did some improvments in buildout and didn't change the tests in zope3recipe. Could this be the case? Regards Roger Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Retire zope.app.boston
Hi Christian Betreff: [Zope3-dev] Retire zope.app.boston Please. It's badly tested and I assume widely unused. I tried to fix a bug that was reported for it and it's just a mess. +1, it was more a tryout then a ready to use package. The problem of this package is, it tries to be compatible with the Rotterdam skin. I agree with retire this package. We can do it better if we need an other ZMI replacement. Or is anybody using it? Regards Roger Ineichen Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope3recipe windows support
Hi Jim and other windows users ;-) I implemented windows support for the zc.zope3recipe. Can you double check this? There is a WINDOWS.txt file including the windows test since they generate different scripts etc. I'm not sure right now if we should implement a windows service in this recipe or if we should implement a own zc.recipe.winserivce for windows service support. Probably we sould offer a windows service installation for a productive server and dispatch the start and stop calles to them. But I don't think we start and stop a windows service within the zdaemon. I guess we only should offer installation and remove methods for the service. The implementation right now is based on a subprocess implementation which get managed by the zdaemon. Any ideas how we can improve the concept? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] help with doctests
Hi Adam
Auftrag von Adam Groszer
Gesendet: Freitag, 20. Juli 2007 09:49
An: zope3-dev
Betreff: [Zope3-dev] help with doctests
Hello,
In z.a.apidoc.browser.README.txt I can write
browser.open('http://localhost/++apidoc++/non-existent/')
Traceback (most recent call last):
...
httperror_seek_wrapper: HTTP Error 404: Not Found
(test passes)
but I can't write
browser.open('http://localhost/++apidoc++/non-existent/')
Traceback (most recent call last):
...
...HTTP Error 404: Not Found
Did you try:
...HTTP Error 404: Not Found...
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Problems with zope3 on windows
Hi Hanno -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Hanno Schlichting [...] Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Right it uses zdaemon which doens't fit for windows. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Can you point me to the right repos/place of this allready fixed issue in Zope2. So I can take a look at that and fix it if I find out how this eggs work. Regards Roger Ineichen Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: [ZODB-Dev] Problems with ZODB3-3.9.0_dev_r77011
Hi Tobias Auftrag von Gary Poster Gesendet: Donnerstag, 19. Juli 2007 15:53 An: Tobias Rodäbel [...] zope.app.keyreference-3.5.0_dev_r77018-py2.4.egg requires ZODB3=3.9.0-dev-r77011 But there might be a caching problem within ZODB3-3.9.0 dev r77011, my debug session tells: /development/Zope3/MyProject/eggs/ZODB3-3.9.0_dev_r77011-py2.4- macosx-10.4-ppc.egg/ZODB/Connection.py(644)_store_objects() - raise (Pdb) obj zope.app.file.image.Image object at 0x3faadb0 (Pdb) oid '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] *** KeyError: '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] = obj *** TypeError: Cache values must be persistent objects. But zope.app.file.image.Image should be persistent. [...] Looking forward to some hints or help, Hi Tobias. The ZODB 3.9 dev version is only different from 3.8 in some conflict resolution code, for which I am responsible. Some thoughts. I'm pretty shure you ve got a LocationProxy arround your object because the zope.app.file doesn't implement ILocation. I've had this issue too and removed the location before I stored the object.With e.g. @apply def photo(): See interfaces.IPersonalData def get(self): photo = self._photo if zope.proxy.isProxy(photo): photo = zope.proxy.getProxiedObject(photo) if photo is not None: proxy = LocationProxy(photo) proxy.__name__ = 'photo' proxy.__parent__ = self return proxy def set(self, photo): if photo is not None: # remove location proxy because the ZODB doesn't like it anymore photo = zope.proxy.getProxiedObject(photo) self._photo = photo return property(get, set) Note: This sample only works in our project because the name is allways ``photo``. Gary - This happens because of the call in ZODB.Connection.py $Id: Connection.py 75693 2007-05-11 22:18:37Z jim $ cool that we have the revision info in the file header ;-) line: 627 except: # Dang, I bet it's wrapped: # TODO: Deprecate, then remove, this. if hasattr(obj, 'aq_base'): self._cache[oid] = obj.aq_base else: raise My question is, can we improve the method: if hasattr(obj, 'aq_base') and remove the proxy with a method that works? Tobias -- Can you agree this? And probably tell us if the obj is a proxy? You can check this by get the type of the object. e.g. type(obj) Regards Roger Ineichen Gary___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] AW: zope.publisher-3.4.0b1_r76188-py2.4.egg
Hi Philipp, Darryl Betreff: Re: zope.publisher-3.4.0b1_r76188-py2.4.egg Darryl Cousins wrote: My buildout update the zope.publisher egg to zope.publisher-3.4.0b1_r76188-py2.4 from zope.publisher-3.4.0a1_1-py2.4.egg. My application is served with paste and I have pasted the traceback below. Please file a bug report in launchpad. Also, if you've already identified the bad checkin, bugging the person who did the checkin helps :). (CCing Roger). I didn't read the previous mails. Did I break something? Regards Roger Ineichen _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] deprecate ++etc++site/default?
Hi Christian Betreff: [Zope3-dev] deprecate ++etc++site/default? Hi there, as far as I am informed it's no longer suggested to put utilities etc. into the default package since the whole package mechanism was not the right idea. Who informed you about that? Is there a proposal for that? One point to change would be zope.app.appsetup.addUtility which puts the utilities into the default package. It should add the utilities directly to the site manager. What are the oppinions here? What is the benefit for that, or what is wrong with the existing setup? Regards Roger Ineichen -- Christian Zagrodnick gocept gmbh co. kg . forsterstrasse 29 . 06112 halle/saale www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] publisher performance
Hi Jürgen Betreff: [Zope3-dev] publisher performance [...] With this new version I also measured the time with zope as a trunk checkout (no eggs involved). The publisher is now twice as fast as it was before ! I'm writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core. newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher. What do you mean with and without eggs? Do you mean the flat dotted page name structure used in eggs? Does the egg package structure perform different in some way? Or do you mean something else? Regards Roger Ineichen Regards Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: publisher performance
Hi Juergen Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jürgen Kartnaller Gesendet: Sonntag, 17. Juni 2007 06:43 An: zope3-dev@zope.org Betreff: [Zope3-dev] Re: AW: publisher performance Roger Ineichen wrote: Hi Jürgen Betreff: [Zope3-dev] publisher performance [...] With this new version I also measured the time with zope as a trunk checkout (no eggs involved). The publisher is now twice as fast as it was before ! I'm writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core. newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher. What do you mean with and without eggs? Do you mean the flat dotted page name structure used in eggs? Does the egg package structure perform different in some way? Or do you mean something else? With without eggs I mean I used a trunk checkout for zope. With eggs I mean I use the eggified packages from zope. Yes, I understand this, but I'm curios about you commit message: checkin 76706 says: Removed stack extraction in newInteraction. When using eggs this is an extremly expensive function. The publisher is now more than 10 times faster when using eggs and about twice as fast with a zope trunk checkout. Why makes this improvment eggs distribution 10 time faster and the trunk only 2 times? Do I get this right? Do we pay the flat dotted package structure, which eggs bring with, pay with slower excecution time? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] a ConflictError grabbag: problems and solutions inzope.app.keyreference and zope.app.session
Hi Gary Betreff: [Zope3-dev] a ConflictError grabbag: problems and solutions inzope.app.keyreference and zope.app.session [...] I suppose a compromise would be to make a zope.minmax, and then have zope.app.session depend on it. That would be fine by me, but making a zope.* package requires agreement from interested parties. If I got this right, there is no there is no drawback, right? If so, it whould be better to have such improvments in zope in general. I guess having such improvments in optional packages whould end in not using it for none core developer and make zope more magicly as it allready is right now for beginners. Regards Roger Ineichen _ END OF MESSAGE Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: [Checkins] SVN: z3c.form/trunk/src/z3c/form/ HTMLelement ids containing dots are not very good, because then the
Hi Gary
Betreff: [Zope3-dev] Re: [Checkins] SVN:
z3c.form/trunk/src/z3c/form/ HTMLelement ids containing dots
are not very good, because then the
[...]
If you can send me a z3c.form-based form that does not behave
correctly in IE6, I will be more than glad to revert this
change and
find another solution to the problem.
I won't have time to do that anytime very soon. We
encountered this problem again very recently actually.
Here's a very small test case. Works correctly on Firefox,
breaks on IE 7(!).
I see, that's a known bug in IE.
input type=submit name=foo id=bar value=Bar /
input type=submit name=baz id=foo value=Foo /
Using the same id and name in different elements
ends in IE with getting the first element with that
id or name. This means getElementById('foo') will
return the first element found with the given
name=foo or id=foo.
The z3c.form framework avoids this perfectly because it
generates element names and ids like:
id=form-widgets-lastname name=form.widgets.lastname
This will make sure that we never generate equal names
and ids for all form elements.
Regards
Roger Ineichen
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: [Checkins] SVN: z3c.form/trunk/src/z3c/form/ HTMLelement ids containing dots are not very good, because then the
Hi Stephan, Gary, Marius Betreff: [Zope3-dev] Re: [Checkins] SVN: z3c.form/trunk/src/z3c/form/ HTMLelement ids containing dots are not very good, because then the On Jun 3, 2007, at 12:58 PM, Stephan Richter wrote: Log message for revision 76258: HTML element ids containing dots are not very good, because then the element#id CSS selector does not work and at least in firefox the attribute selector (element[attr=value]) does not work for the id either. Thus I converted the entire codebase to use dashes in ids instead. I am sorry if this causes some test-fixing issues for some of you, but making this change sooner rather than later is better in the long run. I am going to test this some more now. Hey. I've only had limited time to look at the new package(s) but what I've seen so far looks good. I hope to give it a whirl soon. You may want to check about the browser compatibility of having ids and names different. I know I used to have IE problems when I did this. I tried to Google for verification. I think you'll find some here: http://channel9.msdn.com/wiki/default.aspx/ Channel9.InternetExplorerProgrammingBugs Look for the section titled META tags improperly register them selfs as an ID with document.getElementById(), specifically the *second* example. AFAIK, this would be an IE6 thing; I don't have much hands-on pain knowledge with IE7. In fact, HTML 4 does regard name and id to be in the same namespace for anchor tags (see http://www.w3.org/TR/html4/struct/links.html, 12.2.3) and even requires that they be identical (example is in the section). The IE bug, apparently, is to assume that this constraint holds for all name attributes, such as form fields. So, what you did is technically correct. However, if you want your code to be used be folks who care about supporting IE6 and JS, I believe you will want your names and ids to be identical. Agreed, we can't use different names and ids! We can use camel bucket names instead of dots. This means we can convert each first letter of a prefix to a uper case letter. But the first letter should be lower case. This wil give us names and ids like: formWidgetsLastname rather then: form.widgets.lastname This should also work if somebody uses already a camel bucket name for lastName e.g. form.widgets.lastName /formWidgetsLastName because we do not need to resolve/split the prefix based on the formWidgetsLastName string base. We do only split such prefixed strings based on the prefix parts itself. But another question is, why do we use additional dots or someting else between prefixes? I guess we should skip it and just append each prefix. This alloes us to use the pattern above as well by choosing our own camel bucket names if needed. Any reason for using dot prefix for our prefixes? If not I propose to skip the additional dots which are only beautifiers. What do you think? I've rung this alarm bell before in other contexts, but this is the first time I was able to find corroboration. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ 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 C++
Hi Adams Great, thanks a lot. Regards Roger Ineichen _ END OF MESSAGE -Original Message- From: Adam Groszer [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 8:54 AM To: Roger Ineichen Cc: zope3-dev@zope.org Subject: Re: [Zope3-dev] Zope3 C++ Hello Roger, It's done. http://www.zope.org/Products/Zope3/Trunk/swrelease_contents Friday, March 9, 2007, 1:56:54 AM, you wrote: Hi Adam Can you build new *.pyd files and zip them? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/agroszer%40gmail.com -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope3 C++
Hi Adam Can you build new *.pyd files and zip them? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ZPT missing header
Hi all Some test do not pass in our application with the newest Zope3 trunk. Can somebody explain what's happen to the meta header info. In our Page Template the following header get lost: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Regards Roger Ineichen _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] z3c.javascript eggs now available
Hi Paul Subject: Re: [Zope3-dev] z3c.javascript eggs now available [...] Do whatever you like to do within the javascript sources in the z3c.javascript packages. Right now it's not useable because the javascript versions are not documented the package are using. Finally, the current layout of the z3c.javascript repository makes doing eggs for individual subpackages (dojo, mochikit, etc.) a pain and I don't think anyone wants to download a single 14mb egg for the entire z3c.javascript package. Would it make sense to put z3c.javascript.* subpackages into the root of the zope repository? Also, I'm about to send in a zope contributor agreement form so that my packaging files can make it into the zope repository. Is it not possible to build eggs for sub packages of z3c.javascript? Must they be top level packages? If so, that's a problem for other packages in z3c too? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] z3c.javascript eggs now available
Hi Paul, Hi Bernd Subject: [Zope3-dev] z3c.javascript eggs now available I have made my very first set of eggs for each of the packages in z3c.javascript. They are available at http://eggs.carduner.net I would love it if interested people would check them out and verify that they work and/or are properly built and/or have the proper metadata, before I think about uploading them to the cheeseshop. Thanks for the effort and your work. I like it. But Im' sure we need a concept before this packages get distributed. I think it should be possible to have tags for each stabel version of the mirrored javascripts. I think just to have one actualy version is not enough. What do you think? Do we realy need to support our own javascrip mirror? Or should we degrade our z3c.javascript packages and remove the copied javascript itself? Regards Roger Ineichen Thanks, Paul Carduner ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ 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: Bug in zc.catalog.index
Hi Gary Subject: Re: [Zope3-dev] Re: Bug in zc.catalog.index [...] I just made a 1.1 branch (svn+ssh://svn.zope.org/repos/main/ zc.catalog/branches/1.1). For now, I suggest you move to that branch (or to the tag or PyPI release!). Meanwhile, we'll make a new version of 1.1 that does contain sniffing code and also contains a generation script. We'll release 1.1.1 and 1.2.0a-rev(some revision number...). The migration path will be as follows: move to 1.1.1 (or svn up/switch to 1.1 branch) run migration script move to 1.2/trunk I don't have an ETA for you, but we will try to have it in the next day or two. Thanks Gary, that's fine for me. Regards Roger Ineichen _ END OF MESSAGE Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Bug in zc.catalog.index
Hi alga Is this mine or is there something wrong with zc.catalog.index, BTreeAPI or? - self._add_value(doc_id, value) File D:\reflineRecruiter\app\trunk\src\zc\catalog\index.py, line 115, in _add_value values_to_documents[added] = self.BTreeAPI.TreeSet((doc_id,)) AttributeError: 'module' object has no attribute 'TreeSet' - Any hints? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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: Broken tests since last checkout
Hi Philipp
Subject: [Zope3-dev] Re: Broken tests since last checkout
Roger Ineichen wrote:
Since the newest Zope3 trunk checkout, some tests are not running.
This tests are based on a custom test layer.
Exception raised:
Traceback (most recent call last):
...
raise ConfigurationError('No registered publisher found '
ConfigurationError: No registered publisher found for (GET/)
Does anybody have any hints why the publisher is missing?
Looks to me something's going wrong when loading
zope.app/configure.zcml. This was refactored recently (you're
now supposed to load zope.app.zcmlfiles/configure.zcml), but
backwards-compatibility should've been provided.
Thanks for the feedback. I changed this earlier. My problem
was, that the new layer concept needs it's own ftesting.zcml
file setup.
Roger Ineichen
_
END OF MESSAGE
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Broken tests since last checkout
Since the newest Zope3 trunk checkout,
some tests are not running. This tests are based
on a custom test layer.
Exception raised:
Traceback (most recent call last):
File D:\trunk\Zope3\src\zope\testing\doctest.py, line 1361, in __run
compileflags, 1) in test.globs
File doctest README.txt[4], line 1, in ?
manager.open('http://localhost/sampledata.html')
File D:\trunk\Zope3\src\zope\testbrowser\browser.py, line 223, in
open
self.mech_browser.open(url, data)
File D:\trunk\Zope3\src\mechanize\_mechanize.py, line 177, in open
return self._mech_open(url, data)
File D:\trunk\Zope3\src\mechanize\_mechanize.py, line 202, in
_mech_open
response = UserAgent.open(self, self.request, data)
File D:\trunk\Zope3\src\mechanize\_opener.py, line 234, in open
response = urlopen(self, req, data)
File C:\Python24\lib\urllib2.py, line 376, in _open
'_open', req)
File C:\Python24\lib\urllib2.py, line 337, in _call_chain
result = func(*args)
File D:\trunk\Zope3\src\zope\testbrowser\testing.py, line 123, in
http_open
return self.do_open(PublisherConnection, req)
File C:\Python24\lib\urllib2.py, line 993, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File D:\trunk\Zope3\src\zope\testbrowser\testing.py, line 80, in
request
self.response = self.caller(request_string, handle_errors)
File D:\trunk\Zope3\src\zope\app\testing\functional.py, line 592, in
__call__
environment)
File D:\trunk\Zope3\src\zope\app\testing\functional.py, line 625, in
chooseRequestClass
return chooseClasses(method, environment)
File D:\trunk\Zope3\src\zope\app\publication\httpfactory.py, line
33, in chooseClasses
factory = factoryRegistry.lookup(method, content_type, environment)
File
D:\trunk\Zope3\src\zope\app\publication\requestpublicationregistry.py,
line 97, in lookup
raise ConfigurationError('No registered publisher found '
ConfigurationError: No registered publisher found for (GET/)
Does anybody have any hints why the publisher is missing?
Regards
Roger Ineichen
_
END OF MESSAGE
___
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] Zope 3.3.1 released
On Behalf Of Philipp von Weitershausen Subject: [Zope3-Users] Zope 3.3.1 released [...] You can find more information as well as a tarball for Unix and a Windows installer at http://www.zope.org/Products/Zope3/3.3.1. Thanks a lot Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] wiki site broken in IE
Hi The http://wiki.zope.org/zope3/FrontPage site is totaly broken in IE. The scrollbar is gone and it's not possible to scroll to the bottem of the content. Can somebody fix that or tell me where I can find the source of the wiki page skin? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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: spurious viewspace slot?
Hi Thomas Subject: [Zope3-dev] formlib: spurious viewspace slot? Hi, while working on one of our projects at gocept, we noticed that formlib's pageform.pt template defines a viewspace slot which we feel it shouldn't, as the Rotterdam skin's template.pt has a div defining the same slot and carrying the same id. We found this because of an extraneous line inside the viewspace of one form, which turned out to be a top border specified for the viewspace ID. Should the viewspace slot be removed from pageform.pt? I think that's not a good idea because this could be incompatible with others work. The formlib tempaltes are used in many project. Note, in many project the formlib is used without the Rotterdam skin and this isn't a problem. What you can do is, remove the duplicated id in the Rotterdam skin. I guess/hope this will not affect others work. Or at least will only end in a visualy broken layout. Does it work if you rename the div id in the Rotterdam skin template and CSS? Regards Roger Ineichen _ END OF MESSAGE -- Viele Grüße, Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] formlib and href anchor?
Hi and a late happy new year, I just like to know if anybody implemented a href anchor support for formlib? Or does anybody use a own custom concept for support anchor in large forms? Or does anybody have expiriences (even bad onces) in supporting anchors in z3? Any ideas? Regards Roger Ineichen _ END OF MESSAGE ___ 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: [SpringCleaning07]
Hi Martijn I saw the Grok package but what is Genshi? Can you point me to a link? http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) Looks great in a first overview. Let me know if you or somebody else starts to port it to z3. I'm interessted to using another template language in z3 too. Thanks for the hint Roger 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: [SpringCleaning07]
Hi Jim, It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the tags that shouldn't be minimized issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. What's up with jsonserver? Did you move the package to a new repository? Can you offer a mailinglist for the zif packages? I'm very interested in observing the state of jsonserver since we use it most projects. Can you give a short statement about the zif and jsonserver repo? Regards Roger Ineichen -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ 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: [SpringCleaning07]
Hi Jim, Subject: Re: [Zope3-dev] Re: [SpringCleaning07] What's up with jsonserver? [...] Hi, Roger [...] For the moment, the Zif Collective is all alpha and experimental on SourceForge. Nothing released. Nothing to be alarmed about. Nothing decided about other repositories. That's ok for me. Just keep it going and tell us if you have more such nice packages like jsonserver. Regards Roger Ineichen -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: [SpringCleaning07]
Hi Baiju Subject: [SpringCleaning07] Here is a list of candidates for removal (please verify!): zope.dependencytool zope.fssync zope.importtool zope.modulealias zope.sequencesort zope.wfmc zope.xmlpickle zope.app.dtmlpage zope.app.file zope.app.fssync zope.app.zptpage -- What does removal mean? Regards Roger Ineichen _ END OF MESSAGE forwarded from http://wiki.zope.org/zope3/SpringCleaning07#msg20061218200418- [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RE: [SpringCleaning07]
Hi Christian, Baiju Subject: Re: [Zope3-dev] RE: [SpringCleaning07] Hi, Roger Ineichen wrote: What does removal mean? We have two possible situations for a package that I'd like to consider during spring cleaning: 1. packages that are in the src/ tree but are not distributed with Zope releases The question is whether those packages are maintained and there is interest to keep them around. If they are not maintained and there is no interest from anybody, we can either put them into a retirement section or just delete them. 2. packages that are distributed but untested/unmaintained/unused Those should eventually not be distributed anymore and maybe have the same destiny as packages from 1. I try to support Jims vision of a smaller core system with this. However, those packages that are currently distributed need to be considered very carefully and require a deprecation cycle. As deprecating things that are used by other people is bad IMHO, we should be very sure that we don't annoy people by doing so. +1 I'm fine with that as long as the zope.app.file is contained in the distribution. Regards Roger Ineichen _ END OF MESSAGE Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ 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: [SpringCleaning07]
Hi Subject: Re: [Zope3-dev] RE: [SpringCleaning07] - zope.app.demo This is a really tricky one. The point of the package is to collect demonstration code and the point of it living in zope.app is that it will always work. But does it belong here? I do not know. What do others think? I vote for remove this package from the core. - zope.app.styleguide This package contains Zope 3 coding style conventions, but I am not sure it is used as the canonical source for the conventions. I think the Wiki is more central. I know Roger put a lot of time into the package, so maybe we can put the information not contained in the wiki there and then remove the package. I'm fine with removing this package from the distribution and copy the content into a wiki. I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists. I think we should find maintainers for every package or a bunch of them and cleanup strictly all other parts. Perhaps this will give us a positive sideeffect in fixing bugs. Perhaps it's realy time that the zope foundation give us a OK to implement the ZSCP process. If we whould have such a process we shouldn't have a problem with unmentained packages in the future. Regards Roger Ineichen Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [SpringCleaning07]
Hi Martijn Subject: [Zope3-dev] Re: [SpringCleaning07] By the way, I'm quite interested in seeing whether we can integrate Genshi into Zope 3 and Grok as a templating language. It has some interesting ways to do things, and there's quite a bit of momentum behind it. I saw the Grok package but what is Genshi? Can you point me to a link? Regards Roger Ineichen _ END OF MESSAGE Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Rename sandbox in trunk - z3c.widget
Hi all I changed the name of z3c/widget/sandbox to z3c/widget/trunk. If you are using some z3c widget packages please adjust the svn externals. Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for'zope.app' 1? What's a good practice to update to generation 5prior to my own evolver?
Hi Jeff Behalf Of Jeff Shell Sent: Monday, November 06, 2006 8:19 PM To: Zope 3 Development Subject: Re: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for'zope.app' 1? What's a good practice to update to generation 5prior to my own evolver? [...] I fix a bug in generation evolving for generation 3. See the checkin message for revision 71115. It's also backported to Zope 3.3 in revision 71116 Probably this has something to do with our problem. Regards Roger Ineichen _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: [Eggification of Zope Packages]
Hi Baiju, agreed Can you tell me if it's possible to build eggs out off the box on windows or do I have to do something before I can build eggs with windows? Can you give me some hints or point me to the right direction? If so, I can start building eggs for the z3c packages. Regards Roger Ineichen _ Projekt01 GmbH I think zc.*, z3c.*, and lovely.* packages can be tracked seperatly for both eggification and zc.buildout support. But we can add tracking of zc.buildout-ification of zope.* packages here itself. -- forwarded from http://wiki.zope.org/zope3/EggificationOfZopePackages#msg20061 [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope3 trunk doesn't start
Hi all How drops the bforest package out of the zope package? Do we get bforest package back or should we drop the API doc registration too for bforest too? Traceback (most recent call last): File z3.py, line 64, in ? run() File z3.py, line 60, in run main(argv[1:]) File D:\projektCompiler\trunk\src\zope\app\twisted\main.py, line 73, in main service = setup(load_options(args)) File D:\projektCompiler\trunk\src\zope\app\twisted\main.py, line 142, in setup zope.app.appsetup.config(options.site_definition, features=features) File D:\projektCompiler\trunk\src\zope\app\appsetup\appsetup.py, line 110, in config context = xmlconfig.file(file, context=context, execute=execute) File D:\projektCompiler\trunk\src\zope\configuration\xmlconfig.py, line 589, in file context.execute_actions() File D:\projektCompiler\trunk\src\zope\configuration\config.py, line 612, in execute_actions callable(*args, **kw) File D:\projektCompiler\trunk\src\zope\app\onlinehelp\onlinehelp.py, line 123, in registerHelpTopic raise ConfigurationError( zope.configuration.config.ConfigurationExecutionError: zope.configuration.exceptions.ConfigurationError: Help Topic definition D:\projektCompiler\trunk\src \zope\bforest\bforest.txt does not exist in: File D:\projektCompiler\trunk\src\zope\app\apidoc\bookmodule\book.zcml, line 213.4-217.10 bookchapter id=bforest title=BForest API doc_path=bforest.txt / Regards Roger Ineichen _ Projekt01 GmbH ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: Re[4]: [Zope3-dev] possible bug in zope.wfmc
Hi Adam Hi Roger, Tuesday, September 19, 2006, 12:08:20 PM, you wrote: Update - Final is guarded by review_result == 'accepted' Update - Issue is guarded by transitionName == 'update_issue' Update - Review is guarded by transitionName == 'update_review' RI Is this (Update - Final) not a end transaction? RI Do you mean that the end transaction concept istn't correct working? Taken the above example, if review_result == 'rejected' and transitionName == 'final' when I fire workItemFinished in the workflow application neither condition is true. That makes zope.wfmc think that there are no outgoing transitions and proceeds to the finishes the process. The example is bad for this, because if there would be some activities after Final they would be skipped and the whole process would be finished. Hope that makes the picture clear. Yes, but this sounds not good to me. RI Sorry, I don't know. but I agree that it should be a difference if RI we finsih a transaction with a Fslse or True guard. I'm trying to get some answers at http://www.workflow-research.de/Forums , which should be an official forum for WFMC. Hope you get a better answer there then from me. I'm not sure what the behavior should be. - should you not offer the transistion for processing in such a usecase (but what if this is a automatic transition?) - Should you catch this usecase with a error message like you said before - Or should you let pass the trasnistion to the end because this is a miss configuration I really don't know what the recommended way should be, but you could make sure catching this usecase and implement a kind of fallback transition and do something what you need to do and avoid to get processed to the end. This could probably be a workarround which makes it working without implementing a error message. Regards Roger Ineichen -- Best regards, Groszer Adam -- Quote of the day: Criticism, like rain, should be gentle enough to nourish a man's growth without destroying his roots. - Frank A. Clark ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: Re[2]: [Zope3-dev] possible bug in zope.wfmc
Hi Adam, Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Groszer Sent: Monday, September 11, 2006 4:27 PM To: Jim Fulton Cc: zope3-dev Subject: Re[2]: [Zope3-dev] possible bug in zope.wfmc Hello Jim, My specific usecase is: - -| Final | -- / - ...--| Update |- - -- \-| Issue |--... ^ \ - |\-- | \--| Review | | -- | | +--+ Update - Final is guarded by review_result == 'accepted' Update - Issue is guarded by transitionName == 'update_issue' Update - Review is guarded by transitionName == 'update_review' On the UI I put up every possible transition. Now if my crazy user chooses Final if review_result != 'accepted' then bang, the process gets finished. No errors, no messages, no exceptions. I already thought of filtering the possible transitions on the UI, but how? transitionName still forces the other conditions to false. A kind of transition-precondition is not available as I know. In this usecase raising an exception and thus not letting any transition to fire fits me perfectly. Is this (Update - Final) not a end transaction? Do you mean that the end transaction concept istn't correct working? XPDL would give the options - exception - default exception - otherwise but none of these are implemented in zope.wfmc. I think finishing the whole process is definitely bad behaviour. But what's correct? Please give a hint what should be done. Sorry, I don't know. but I agree that it should be a difference if we finsih a transaction with a Fslse or True guard. Regards Roger Ineichen Monday, September 11, 2006, 4:00:01 PM, you wrote: JF On Sep 10, 2006, at 9:00 AM, Adam Groszer wrote: Hello, I think I found a bug in zope.wfmc. Let's say the ReviewPublish and ReviewReject transitions are guarded by conditions. --- --| Publish | -- -- / --- | Author |--| Review |--- -- -- \--| Reject | -- If at Review.workItemFinished() both conditions are still _FALSE_ the wfmc package finishes the whole process. I think the correct behaviour should be to not to allow to finish the workitem. JF I don't think that would be correct. Maybe an exception should be raised? JF You can actually model that in xpdl using an exception, although I JF don't reflect off-hand if that is supported in zope.wfmc. JF Jim JF -- JF Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! JF CTO (540) 361-1714 http://www.python.org JF Zope Corporationhttp://www.zope.com http://www.zope.org -- Best regards, Groszer Adam -- Quote of the day: Money, not morality, is the principle commerce of civilized nations. - Thomas Jefferson - ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c - be or not to be
Hi to all Zope3 Visionairs ;-) CC: to some of the z3c namespace chooser which are to busy to answer, flying back to Boston or are at holiday this week ;-) Yes, I didn't do much for Zope3 core the last couple month, except publishing to z3c. But as on of the initiator of z3c I need to give a statement before it turns me crazy. I only speak for myself here, but I guess the rest of the active z3c developer, package user team can agree on the following: I (we) will *NOT* rename the z3c namspace. We never told that z3c is the *ONLY* namespace for z3 community. Let's see the z3c namspace as some usefull packages commited from a team of z3 developers they work and share its work. I'm sure and hope there is more space for other developer teams using it's own namespace. The reason why; We really have no time to do this in the next couple of month. And the option sombody else doing it is also *NO* option because we have allready productive projects build on this libraries and have no time to migrate them for nothing. Yes renaming the z3c namspace whould technicaly possible, but for me(us) it's just a waist of time right now. Could be that I will change my mind in the future but not in the next couple of months. btw, Onw of my next task, whould be to update the documentation and write more tests, but for sure not to change a namespace. Philipp, Renaming sandbox to trunk in some z3c pkgs is one of my first steps I will do if I'm finished the next project. Or does anybody else take this task? Regards Roger Ineichen _ Projekt01 GmbH ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Erros on Zope3 trunk
Hi
I get two errors on a fresh Zope3 checkout on
my Windows XP box
Failure in test testStandalone (zope.component.tests.StandaloneTests)
Traceback (most recent call last):
File C:\Python24\lib\unittest.py, line 260, in run
testMethod()
File D:\projektZ3C\Z3C\Zope3\src\zope\component\tests.py, line 975, in
testStandalone
self.fail(''.join(lines))
File C:\Python24\lib\unittest.py, line 301, in fail
raise self.failureException, msg
AssertionError: Traceback (most recent call last):
File D:\projektZ3C\Z3C\Zope3\src\zope\component\standalonetests.py, line
8, in ?
from zope import interface
File D:\projektZ3C\Z3C\Zope3\src\zope\interface\__init__.py, line 55, in
?
from zope.interface.interface import Interface, _wire
File D:\projektZ3C\Z3C\Zope3\src\zope\interface\interface.py, line 23,
in ?
import weakref
ImportError: No module named weakref
-
and
-
Failure in test test_setProxiedObject (zope.proxy.tests.test_proxy)
Failed doctest test for zope.proxy.tests.test_proxy.test_setProxiedObject
File D:\projektZ3C\Z3C\Zope3\src\zope\proxy\tests\test_proxy.py, line
617, in test_setProxiedObject
--
File D:\projektZ3C\Z3C\Zope3\src\zope\proxy\tests\test_proxy.py, line 620,
in zope.proxy.tests.test_proxy.test_setProxiedObject
Failed example:
from zope.proxy import setProxiedObject, getProxiedObject
Exception raised:
Traceback (most recent call last):
File D:\projektZ3C\Z3C\Zope3\src\zope\testing\doctest.py, line 1361,
in __run
compileflags, 1) in test.globs
File doctest zope.proxy.tests.test_proxy.test_setProxiedObject[1],
line 1, in ?
from zope.proxy import setProxiedObject, getProxiedObject
ImportError: cannot import name setProxiedObject
--
Seems that the tests are not importing the correct packages.
-
Mit freundlichem Gruss
Roger Ineichen
_
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 Hünenberg
phone +41 (0)41 781 01 78
mobile+41 (0)79 340 52 32
fax +41 (0)41 781 00 78
email [EMAIL PROTECTED]
_
END OF MESSAGE
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Tim, new pyd zip file needed
Hi Tim or Adam Can you generate a new *.pyd zip download? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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: Tim, new pyd zip file needed
Thanks Adam Regards Roger Ineichen _ END OF MESSAGE -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Groszer Sent: Monday, August 21, 2006 12:19 PM To: Roger Ineichen Cc: zope3-dev@zope.org Subject: [Zope3-dev] Re: Tim, new pyd zip file needed Hello Roger, Just uploaded to http://www.zope.org/Products/Zope3/Trunk Hope that the 3.3.0b2 pyds are OK for you. Monday, August 21, 2006, 12:08:15 PM, you wrote: RI Hi Tim or Adam RI Can you generate a new *.pyd zip download? RI Regards RI Roger Ineichen RI _ RI Projekt01 GmbH RI www.projekt01.ch RI Boesch 65 RI 6331 Hünenberg RI phone +41 (0)41 781 01 78 RI mobile+41 (0)79 340 52 32 RI fax +41 (0)41 781 00 78 RI email [EMAIL PROTECTED] RI _ RI END OF MESSAGE -- Best regards, Groszer Adammailto:[EMAIL PROTECTED] -- Quote of the day: Liar: One who tells an unpleasant truth. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Pluggable authentication id management
Hi Jim, [...] I think this is not posible. What if you have a PAU with two authenticator plugins in it. Then you can't delegate the prefix from the PAU to both authenticator durring a generation and provide a unique plugin prefix on authenticator level. I said prepend the PAU prefix to each plugin's prefix. The plugin's prefixes would already have provided uniqueness within the PAU. Prepending the PAU's prefix would simply duplicate what is being done now at run time. Ah Ok, I see what you mean. Regards Roger Ineichen Jim -- Jim Fultonmailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Backward-incompatible bug fix to zope.proxy
Jim Fulton schrieb: [...] Hi Jim, We just use a IContainer location proxy adapter. But since this adapter isn't persistent I don't think this is a problem. def proxify(container, item): if IContainer.providedBy(item): proxy = ContainerLocationProxy(item) else: proxy = LocationProxy(item) proxy.__name__ = item.__name__ proxy.__parent__ = container return proxy class ContainerLocationProxy(LocationProxy): Proxy the location of a container an its items. # zope.app.conatiner.interfaces.IReadContainer def __getitem__(self, key): return proxify(self, getProxiedObject(self).__getitem__(key)) ... Well, with the fix, your __getitem__ won't be called. Is that a problem? ;) You will need to use the @non_overridable decorator on your __getitem__ function. If I understand this correctly, then we only have to update the methods with decorators? If so, this will be fine for me. Jim -- Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Making zope.app smaller
Hi Jim and Philipp [...] What are the things that people could help you with? When I get a bit further, it would help a lot if someone could work on the new registration UI. If anyone is interested, please let me know. Perhaps we can do some work at the next Sprint here in switzerland. Does Stephan know what's to do? Or can you give me more info about what you need? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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
Philipp von Weitershausen schrieb: Roger Ineichen wrote: class LanguagesVocabulary(SimpleVocabulary): ... languages from a translation domain. implements(ILanguagesVocabulary) def __init__(self, context, domain='zope'): terms = [] # collect languages from translation domain trans_domain = getUtility(ILocalTranslationDomain, domain) languages = trans_domain.getAvailableLanguages() for lang in languages: terms.append(SimpleTerm(lang, lang, lang)) terms.sort(lambda lhs, rhs: cmp(lhs.title, rhs.title)) super(LanguagesVocabulary, self).__init__(terms) 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. I need to do this in python for each language vocabulary. So we defently loose the ZCML as a compoent registration layer and need a additional layer called python for registering a component! I think you didn't understand what this means? Are you realy think it's a better option to have a mix of python and ZCML for register components? I could live with that, but I don't understand why I loose additional to this the reusablility and also the readability in ZCML? I think utility component=.tiksLanguagesVocabulary name=Tiks Languages / reads quite well. Why should I do this in ZCML if I have to do the first part of a configuration in python. There is realy no reason to define this in ZCML if I have to define the factory. It will become a YAGNY and developer start to do this: def tiksLanguagesVocabulary(context): return LanguagesVocabulary(context, 'tiks') factory = tiksLanguagesVocabulary() provideUtility(factory, name=Tiks Languages) I'm not sure what do you think. Do you think it's a way we should go or not? I think that's defently no way to go. Philipp can you tell me why this is better if we loose the concept for quick adding a new utility providing kws like the 'domain' attribute in example. I explain this in the proposal: First, it is the only directive to take arbitrary arguments and by this it defies one of the initial aspects of ZCML (which is being restricted to a certain set of directives and parameters). That's no true, The vieletManager uses this pattern too. And the base pattern which makes it possible is well known in python. (args, kws). Do you also mean this isn't a good concept? I gree with you if you saying that arbitary arguments are to magic in ZCML. But another option then remove this is to document it. Isn't that the real problem? Is ZCML only to magic and hard do understand becaus of to less documentation and samples? (off Topic) I realy don't understand that people can understand and work with Plone and say that ZCML is to magic? But perhaps this is because Ploen is well documented and ZCML directives are not;-) So this means if I need another LanguageVocabulary utility for a new domain, I have to write new factory, just for use another domain='foobar' attribute. Should we add the vocabulary directive to a higher level namespace What is a higher level namespace? Either way, I'd rather reduce the amount of namespaces we have (perhaps to just the 'zope' one and 'browser'). Reduce the namespace is welcome. I vote for a single namespace called zope and merge the browser:view and zope:view to one. But the problem is you removed a hole concept called vocabulary directive. This concept contains: - reduce lines of python code, - Offers a understandable (informative) name in form a of a directive - Makes vocabularies resuable without write additional python code The big problem we have is, we have a different meaning what ZCML should be. I think ZCML supports registration and python supports everything except configuration. I like a strict separation if possible. Now you are going in a direction where we mix both concept with each other. Which will end in a chaos and is not easy to support. Let me explain this a little more. The following pyhton class defines the vocabulary: class LanguagesVocabulary(SimpleVocabulary): ... languages from a translation domain. implements(ILanguagesVocabulary) def __init__(self, context, domain='zope'): terms = [] trans_domain = getUtility(ILocalTranslationDomain, domain) languages = trans_domain.getAvailableLanguages() for lang in languages: terms.append(SimpleTerm(lang, lang, lang)) terms.sort(lambda lhs, rhs: cmp(lhs.title, rhs.title)) super(LanguagesVocabulary, self).__init__(terms) And now we have(had) two ways doing the configuration: pure ZCML: vocabulary name=Tiks Languages factory=.tiksLanguagesVocabulary domain=tiks / then new concept requires a mix from
[Zope3-dev] What is ZCML?
What do you think about the following: We have three concept in Zope 3 which are the real base for Zope 3 as application server. This are: - python - Zope components - ZMCL Each of them are well separated. Python is well documented, Zope 3 is also good documented for a devleoper in it's REAMDE.txt files and unit tests. And ZCML is sometimes pure magic because of it's different intepretation what it should be. I'm a little worry about in what direction ZCML is going. Right now we have two options. This are: - ZCML as a registration layer. - ZCML as a configuration layer. What does this exactly mean? This are two targets of ZCML. Some developer think ZCML should only register python defined methods or classes and other think ZCML should configure components which probalbly will need to register classes driven from meta classes or similar thing. The first concept registration can fully be done in python. There is no need for doing it in ZCML. This way ZCML will become a optional concept which also could be replaced by doing directly in python. If we are going in this direction with ZCML I'm sure we don't reflect the component aspect of Zope3 as a Component Framework. The second concept configuration offers ZCML as a standalone concept and ensures that we only use ZCML as the glue for the components. In this concept is the main target to offer a way for reuse Zope3 components without to write additional python code. The API is well defined in different metaconfigure files and the relevant interfaces. I think both concept has their benefit and also are not the answer at all. Right now ZCML is going in the direction of a registration layer which will exclude the option to use ZCML as a configuration layer and register components without to write additional python code. This is bad. Remember the initial target of ZCML. ZCML means Zope Configuration Markup Language and was or is a concept which makes it possible to configure things. The real question now is what are things? Are things: - additional python classes or methods for configure components or - component iself I think the base layers where we use in Zope 3 as a application server are: python -- zope component -- ZCML And I also think: Zope components are easy to handle because the are only based on python and python offers the API which we understand. ZCML could also be so easy if we respect ZCML as a real fully fnctional layer. Which offers the API defined in the different metaconfigure files. But right now ZCML is going in a direction which requires to use Zope components and python as layers. This I think is a fundamental bad thing. We abstract python in Zopes components and additional we get nice interfaces which makes it easy to follow and understand. It could be so easy if we use ZCML as a layer for configure Zope 3 components without to touch the python layer. For me there is no reason strong enough that we should use the python layer for configuration and registration in ZCML. Some people think because it's easier for them to write additional python classes or methods and use the existing python knowlegde that this is enough reason to mix ZCML with python and Zope components. Is this really a good concept? I donp't think so. Propably in the beginning, but how can we handle the complexity when we mix everything with each other? If we go in the direction of ZCML as a registration layer, we have to change the model of our layers and we will get: - python - Zope components - Zope registration components - ZMCL What do you think about that? Are I'm totaly wrong? -- Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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
Philipp von Weitershausen schrieb: Roger Ineichen wrote: You implemented a concept which requires to write additional python code for registration! Wrong. I require addition python code for *creation*. *Registration* is still done in ZCML. Please understand this difference. Before the proposal, ZCML was able configure existing python component. Nope. It *created* new components on-the-fly. Stopping this (because I as many others consider this too magical) was my objective. But on the other hand directlyProvides(..) does also some tings that I have to understand and to use as a replacement for vocabulary I still think it's a question of documentation. You suggest that your python concept is implicit understandable and the ZCML before was not. I say both concept are not understandable without documentation. Yes, but after my proposal I only need to explain vocabularies in one way: They're really utilities providing IVocabularyFactory. Done. I don't need to explain a special, magical ZCML directive. Common, explain the real use case like utlity vocabularies where map a vocabulary name to a interface which was a abritary attribute. That's in both case not this easy. So far in this response I've only reiterated points of my proposal, especially the 3 points in the *Problems* section. I will also note that Jim has made some pretty clear points about this discussion (http://mail.zope.org/pipermail/zope3-dev/2006-February/018265.html), two of which I quote here: - We need to find the riht balence between ZCML and Python. There are many places where we did too much in ZCML. Everybody makes mistakes. That's how we learn. :) I didn't agree with that. We get this mess only because of splitting the configuration declaration in two different implementation layers. (python and ZCML) I think we have a different understanding of what configuration means. To me, ZCML configuration essentially means setting application policy. That includes enabling or disabling of components, making security assertions and setting other certain information (like configuring mailer utilities, etc.). Though it has been suggested that the latter info shouldn't even be in ZCML, either. In any case, configuration doesn't include the creation of components. That's Python's job. Did you see my other mail? The problem now is we use three different abstract development layer for configuration. (python, Zope components, ZCML) Note: If I speak about mix them I mean it should be possible to register python/zope3 components without to write python code. That's what we're doing. Of course, if the components don't exist yet, you *do* have to write some Python code. - As a general rule, things should be defined in Python (or perhaps other definition languages) and *registered* in ZCML. Certainly, core ZCML directives should be about reigistration/configuration not definition. That's excactly the problem. Jim says things without to define it! What is things? Things that are to be registered. Right now there are several places in ZCML were directives 1. create objects and 2. register them. Jim's statement says that #1 should rather be done in Python, whereas #2 remains in ZCML. That's exactly the point of my proposal. Yes, I absolutly understand your point. I'm only not sure if ZCML sould be a own abstract layer in our development process and has to support the configuration at a complete concept. (without requireing pyton) Minimal needed python application code which makes it possible to run and test a application? or also additional python configuration code. And please tell me where was the definition in the vocabulary directive? The vocabulary added the option to register the arbitary attribute well defined in the vocabulary utility class! It's hard for me to understand a sentence that uses arbitrary and well defined at the same time. They contradict. And, if I may add, the arbitrary is actually correct. That's the problem about vocabulary /. If you think not and will be consistent, you have to change the browser:page or browser:view directive and move the name attribute to a pyhton factory as well. That's indeed what I've been thinking about. But I tried to limit the scope of the proposal for now. This is all explained in the Potential follow-ups section of the proposal. Please not Perhaps you should read the proposal again, all I'm doing is referring back to it. I'll also state again that having this discussion now is extremely frustrating as the proposal had been up for discussion for over a month (five weeks, to be exact). Given that the feature freeze was approaching and I yet have other things on my list for Zope 3.3, I needed to make the change at some point. I even gave a heads-up before the merge so that people could review the branch. Sorry you didn't understand me correct. I think your proposal is good. I only will do it in additional
[Zope3-dev] Re: Vocabulary the next proposal
Philipp von Weitershausen schrieb: [...] Jim's statement says that #1 should rather be done in Python, whereas #2 remains in ZCML. That's exactly the point of my proposal. Yes, I absolutly understand your point. I'm only not sure if ZCML sould be a own abstract layer in our development process and has to support the configuration at a complete concept. (without requireing pyton) That's indeed the *key* question. I think Jeff Shell has made some very good points in http://griddlenoise.blogspot.com/2006/03/zcml-needs-to-do-less.html, his main message being: ZCML attempts to do too much, but in the end provides too little when you really want it to be flexible. His example of JavaScript in menu items is brilliant. Yup, this means ZCML should do more and better. I'm just kidding ;-) [...] I've since thought a lot about these directives and I have a compromise in mind. I need to find time to write it down... Let's stop discuss this particular point right here and instead deal with it when the time comes. Ok, agreed Philipp -- Mit freundlichem Gruss Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Swiss Easter Sprint note
Hi Swiss Easter Sprinters, Sorry I don't have each email address right now, and hope to catch you via the zope3-dev and zope3-users mailing list. I setup a mailinglist at [EMAIL PROTECTED] Please subscribe yourself to the list. You can do this by sending a mail with the email address you like to subscribe with a additional body like: Subscribe sprint YOUR NAME You can also get a help mail with subscribe or unsubscribe information if you send a mail to [EMAIL PROTECTED] with the word help in the mail body. If you have problems, send me a note and I will add your email address for you. Please subscribe to this list because we will send additional information via this list and use it to schedule the sprint and we also start to discuss the sprint topics there. You are not a sprint participant? If you are interessted, feel free to add yourself to the list or drop me note if I can do it for you. -- Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ 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?
Martijn Faassen schrieb: Gary Poster wrote: [...] 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. What's 'dobe' mean? I guess he means Bernd Dorn, a developer from austria, he improves the zc.resourcelibrary. -- Mit freundlichem Gruss Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Brainstorming about browser pages
Hi Jeff
-Original Message-
From: Jeff Shell [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 18, 2006 8:05 PM
To: [EMAIL PROTECTED]
Cc: Steve Alexander; [EMAIL PROTECTED]
Subject: Re: [Zope3-dev] Brainstorming about browser pages
On 2/18/06, Roger Ineichen [EMAIL PROTECTED] wrote:
Hi Steve
The advantage of all this is that you need to look in just
one place to
understand a view class. You don't need to look in both
the ZCML and
the Python code, just the Python code. The ZCML becomes
simpler, and
more focused on glueing pieces of Python code together,
and less about
what is to be displayed at what URLs.
Let my say somthing about that.
I like it and I think it's a good way for simplifie view
registration
for a well defined project but not a fremawork where has to offer
a more open API for views.
Why not useable in frameworks;
because this means you have to use PageTemplates for such a API.
But Im OK with this as long we don't propagate this as a reusable
concept for the zope3 core or 3rd party applications.
I like it more to see real Pyhton view API's where can be used
with different templating systems in the future.
I don't understand what you mean by this. At its most basic, a 'view'
in Zope 3 is just a multi adapter. It takes a context object (any
object) and a browser request and provides... Well, whatever it wants
to provide. Not all views are named. Not all views have page
templates. See Absolute URL, for example.
Beyond that, what kind of open API do you need? You can have as open
of an API as you want.
Don't take my comments as the only correct one. This are just
comments focusing on framework or reusable package development.
My comments doesn't allways fit for simply straight forward
product development. (I don't mean quick an dirty here!)
Perhaps my focus was not clearly described. I was thinking about
views for products like a bugracker where other will apply their
layout. In such products I like to have a open view API as possible.
And I don't like to get HTML and CSS from the product if I have to
customize and apply another layout. This is only possible if you
offer view classes not including any PageTemplate mixin.
Some bad samples are for this use case:
template = ViewPageTemplateFile('foo.pt')
or
return div classfoofoo/div
If a product like a bugtracker contains such a views. I have to
replace them and can't use the (view) component within a new
template.
zope.formlib offers a cool way the get rid of hardcoded
ViewPageTemplateFile(), they offer a NamedTemplate which can be
registred for skins and make the view - template relation
customizable.
I guess my concerns about views an a open API was more going in
a direction like:
View - Template/Skinning - Relation
I think projects following a target like Steve describes with
launchpad or you describing below, will not need such a decoupeling
of views and templates. But I think generic frameworks where users
like to apply their layout will need it.
Can you agree on this?
note:
if I use the word view most time I mean a python view class
inherited from formlib.xy or BrowserView etc. (perhaps this is confusing)
I have 3 way multi adapters (context, request, parent view - but not
content providers) that exist purely for formatting. I kept having to
display the same core set of information for an Article - format a
date, turn a user id into a printable name, list tags. There were some
situations where one of those things needed to be formatted
differently: in a search results view, the matching 'tags' needed to
be highlighted. In other views, the 'tags' needed to be links to find
other Articles with that tag. So I made a browser view type object
just for this. Another view (the view listing the articles) is what
calls it and renders the formatted bits that it wants. The adapter is
queried like getMultiAdapter((article, self.request, self),
IFormattedArticleRecord), with ``self`` referring to a browser view.
I break things out like this a lot. I also don't use page templates
very much in these smaller views, but instead use an internal HTML
generation tool with ideas liberally borrowed from Nevow's stan, and
an html helper class to provide a common API for useful common
things (helper is an adapter for a request).
html = cmsapi.htmlHelperFor(self.request)
T = fdlib.tags.builder(indent=2, separator='\n')
outer = T.ul(class_='articles')
for article in self.context.values():
formatted = zapi.getMultiAdapter(
(article, self.request, self), IFormattedArticleRecord)
outer T.li(id='art_%s' % zapi.getName(article))[
html.linkTextTo(formatted.title, html.url(article)),
html.linkTextTo(
'[Delete]', html.viewURL(article, 'delete'),
post=True,
confirm=Delete article %s? %
formatted.title, class_='button
RE: [Zope3-dev] Re: One namespace for ZCML
Hi Philipp [...] Subject: Re: [Zope3-dev] Re: One namespace for ZCML Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). Yes, I agree, that's also a good base for a menu simplyfication. If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). I think it's to complex it right now since I'm not sure at all if my idea will work. Let me try to give a short overview. - Merge the menu and menu item to one implementation - the above will also allow to implement nested menus. Right now the implicit menu, registred in views, don't have a id itself. This means they are unuseful for nested menu registrations. - move menu registration out of the view directives, (like described in your proposal) - Also refactor the IFactory concept. Use IFactory adapters on folders instead of IFactory utilities. The last part IFactory adapters instead of IFactory utilities depends on a application I wrote and was running in serious problems because of the slowdown which depends on IFactory utilies lookups. I'm not sure if somebody will agree on this, but I think if I can profile the IFactory utility implementation and show the slowdown, we have a better base for a proposal. This would also solve some namespace problems we have with the content type name registration. Note; nested menus are implemented since more then a half year. But they are not useable with the existing menu items which are registered inculded in the view directives. Because in the view directive registred menus are only menu items which are not nested. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ 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
Hi Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shane Hathaway Sent: Thursday, February 09, 2006 7:41 PM To: zope3-dev@zope.org Subject: [Zope3-dev] Zope 3 web root An idea just occurred to me. I think others have probably had similar ideas, but didn't express it in the right place or time. Part 1: Let's put an Apache-like web root (similar to /var/www/localhost/htdocs/) in Zope instance homes. It might be called browser or www. Zope will serve pages out of that web root rather than an object database. Part 1 rationale: When people create a Zope instance home, they create some config files and an object database. The root of the site is served out of the object database. To change the default page, newbies are directed to create a default page in the object database. The user didn't ask for an object database. The use of an object database should be a choice, not a requirement. Now the user has to learn some extra tools (fssync, etc.) in order to put the files under version control. I think the user experience for both newbies and experts would be much better if the root of the site were served from a filesystem directory. Part 2: Let's add some ZCML directives that define how to interpret filenames in the web root by their extension. Let's also interpret special per-directory files that map URI names to filenames, similar to Apache .htaccess files. Part 3: One kind of file we can put in the web root serves as a gateway into an object database. We might use the extension .zodb for this purpose. The .zodb file would specify what kind of storage to open, where to find it, and what object to load from it. In a sense, the web root would mount the object database. Some configuration of the web root would mount an object database right at the root, enabling Zope 3 to act just like it does today. Any thoughts or gut reactions? That's a very interesting idea. Do you mean something like this: instance | -- var/poll.fs | -- wwwroot | -- index.html (file system) | -- pollApplication.zodb (zope) | (file with info that point/maps to ../../var/poll.fs) | -- staticFolder (file system) | -- index.html (file system) This means the pollApplication contains a index.html view/page and poll application driven by Zope. Where the rest of the structure is served by static folders and HTML files. Did I got it right? This could be very useful for smaller websites which only need some small dynamic pages and do not need all the overhead from zope. I think about some poll apps or just a view with some database information etc. Regards Roger Ineichen Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Broken homefolder tests
Hi Florian [...] [...] No, this is usually painful tracking down. You could check for test setup code that assigns AttributeAnnotatable to File. Also note that there is no good way for tearing down classImplements() statements. So this issue potentially exists in many places. I think for now it would be okay to add the declaration to the test setup. Ok, I will take a look at this next week. Have a nice week Thanks for fixing that! no problem, that's not really your fault. It's a bad testing teardown concept in z3. We don't really teardown classImplements. This means in your situation the test where only broken if you run the test only for the homefolder package. But the z3 tests running all together where OK. I'm sure you tested the package before you did a commit. I recognized this only because I don't use the bugtracker in our setup. Regards Roger Ieichen Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Broken homefolder tests
Hi Florian [...] No, this is usually painful tracking down. You could check for test setup code that assigns AttributeAnnotatable to File. Also note that there is no good way for tearing down classImplements() statements. So this issue potentially exists in many places. I think for now it would be okay to add the declaration to the test setup. Can I assume that the problem is not in the homefolder package? Sorry, but no you can't. One problem is, that the homefolder README test is broken because of, the File doesn't support AttributeAnnotatable by default. You can add directlyProvides(File, IAttributeAnnotatable) in the test setup. The bad thing is, that the test doesn't fail if you are running all tests at once. This means that another test provides IAttributeAnnotatable for the File. And this another test doesn't teardown correct. Regards Roger Ineichen Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Broken homefolder tests
Hi Stephan [...] No, this is usually painful tracking down. You could check for test setup code that assigns AttributeAnnotatable to File. Also note that there is no good way for tearing down classImplements() statements. So this issue potentially exists in many places. I think for now it would be okay to add the declaration to the test setup. Ok, I will take a look at this next week. Have a nice week Regards Roger Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Broken homefolder tests
Hi Florian, and other unittest gurus? The README.txt test in zope.app.homefolder is failing (trunk). This happens because the zope.app.file.file.File doesn't implement IAttributeAnnotatable in the test setup. The bad thing about this is, that the tests are running if you run all tests at once. This smells like a missing teardown in another test. Does somebody know if there is a method for check if a teardown get called after a test? Some hints? Regards Roger Ineichen ___ 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
Hi Gary [...] 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. Yeah, cool btw, thanks for the nine great packages. I'm looking forward to use them. Regards Roger Ineichen ___ 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: Change CSS on forms
Hi Christian, [...] I'd love to know if there is a strong feeling towards those blue-background-titles. See the proposed changes attached as a patch to zope/app/rotterdam/zope3_tablelayout.css. Regards, Christian btw, do you know that there is a /++skin++Boston/ skin? Regards Roger Ineichen Projekt01 GmbH www.projekt01.ch _ END OF MESSAGE ___ 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
Hi Gary and Jim IMO, the default standard principal search API should use simple string search. I expect that we'll be releaseding our sinmple string search framework soon as part of our Sharing authentication system, which provides a much simpler UI for managing security. (I'm gonna try to get this released before the end of the month.) Yeah, this sounds great. Regards Roger Ineichen Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
