Re: [Zope-CMF] IMember: does it exist?
Paul Winkler wrote: Rob Miller [EMAIL PROTECTED] writes: then CMF does it's normal wrapping of these user objects using the standard MemberData implementation. Hmm, right, so then this might still be on-topic here ;-) Maybe the right thing is for CMF to do a directlyProvides() call in wrapUser? Please consider using alsoProvides() since directlyProvides *overrides* all directly set interfaces. alsoProvides *adds* to them. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Daniel Nouri wrote: Martin Aspeli writes: Yuppie writes: but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to relicense. Re-invention for the sake of a license is just too dumb. I'd prefer to keep the name to avoid breaking existing packages, though. Another option is to factor out a few things to a five.z3cform and have plone.z3cform import from it as appropriate. I just relicensed and moved plone.z3cform to the Zope repository: http://svn.zope.org/plone.z3cform/trunk/ Yay! Despite the plone namespace, it works fine in CMF and pure Zope 2. A namespace is just a name :). *Some* of the functionality (modules) is Plone or CMF specific. The default configure.zcml aims to be usable without Plone or CMF. There's a buildout.cfg in there that pulls Plone. I'd like to replace it with a Zope2-only one (and maybe move the existing buildout to another location). +100 The tests work without Plone. Awesome. By the way, I've collected a few conventions about maintaining software in svn.zope.org: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt It would be nice if everything in svn.zope.org would adhere to these conventions. I'm just mentioning this since there may be some differences to Plone's conventions. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Maurits van Rees wrote: Raphael Ritz, on 2008-05-29: Not sure whether that's following best practice but here is how paster/zopeskel generate this at the moment (this is taken from a custom add-on I'm currently working on): [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs incf incf.applications.egg-info README.txt setup.cfg setup.py [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs HISTORY.txt INSTALL.txt LICENSE.GPL LICENSE.txt How do others handle this? I can understand putting the HISTORY in the toplevel docs/ directory of a package. Btw, the zope.org convention is CHANGES.txt. See [1]. But personally I like having it inside the main folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. That way when changing a file in the main directory and you want to change the history you do not need to descend three directories and go to docs/ to change that. One of the directories is largely superfluous: src. I think the only reason we have it is so that 'setup.py' isn't on the PYTHONPATH. Or something. And in bundles with svn externals the top level docs/ directory is not even visible because you only include the main folder. So you miss the history file (and the README.txt if you keep that in docs/ as well). I think a docs folder adds unnecessary structure in many cases. I remember that at least once I changed something in a plone package inside a bundle, Wichert asked me to update the history file and I ended up wrongly updating the history file of CMFPlone because I never even saw the real history file belonging to that package. :-) That's because bundles are stupid :) [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
On 29 May 2008, at 11:27 , Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: But personally I like having it inside the main folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. You probably want to use a MANIFEST.in anyway and that can easily be used to include everything in doc/ or other places. Good point! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Working with Zope 3 skin layers
Charlie Clark wrote: What I think is still confusing me is: 1) I have created my dedicated skin 2) I have registered a view for that skin I assumed that by registering the view for the skin, the view would automatically use the right layer when called. Views don't use layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. Zope 3 layers and skins work exactly like that. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in Properties page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the interface / directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass interface interface=...IMyDefaultSkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:defaultSkin name=MySkin / Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily switch off those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Uh, it's an interface... how can it not be found? Or how do you not include ICMFDefaultSkin? Using overrides? By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available. PS: in your book the appendix to ZCML browser:defaultSkin says see browser:skin. This has been deprecated, I think. Ah, thank you! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Working with Zope 3 skin layers
Charlie Clark wrote: Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen: Views don't use layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) Um, this is explained in detail in my book. Views are always looked up like this: getMultiAdapter( (context, request), name=foo.html ) (whitespace added for clarification.) So by applying marker interfaces to the request, we can change the output of that adaption. See pages 168-169 in my book. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in Properties page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the interface / directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass interface interface=...IMyDefaultSkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:defaultSkin name=MySkin / Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! That's what's so easy about them! :-O When does the skin name get used apart from in ++skin++ urls? Wherever you'd like to use it. Perhaps you'd like to show a list of available skins to the user so that s/he can choose one. Views are still registered to layers, ie. interfaces, aren't they? Yep. What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an administration layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different skin. Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. I'm not quite sure I'm following you here. Often skins mostly contain custom macros, meaning all views are registered for some default layer (e.g. IDefaultBrowserLayer) and they look up macros using context/@@standard_macros. Then it's up to the specific skin to provide a standard_macros view. This is the one that defines the look and feel of the site and therefore changes from skin to skin. This is exactly what my book explains and does (see Exapmles 10.3.2 and 30.3.3)! Forgive my bluntness, but it's hard to believe at this point you've read it... You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. The IWorldcookerySkin interface doesn't inherit from Rotterdam. And to be honest, I wouldn't know what else to write. I even have a Flashback box that compares Zope 3 style layers to CMF layers and skins on page 173. And what I've written in the two previous emails were mostly rephrased passages from my book anyway. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Working with Zope 3 skin layers
Charlie Clark wrote: I've defined and configured a layer and it works when called by ++skin++ traversal but I have problems if I configured views to work with it explicitly: I get not found errors. ie. browser:page for=Products.Charlie.event.interfaces.IEventDetail layer=Products.Charlie.skin.ICharlieSkin name=detail.html template=detail.pt class=.detail.DetailEdit permission=cmf.ModifyPortalContent / fails for /@@detail.html but Right. This will look up the 'detail.html' view for (context, request). Now it depends on what layers the request has applied to. Unless you've changed anything in the default skin configuration, it will have Zope's default skin. Since the 'detail.html' view above wasn't registered for the default layer but for soemthing else, it's not found. browser:page for=Products.Charlie.event.interfaces.IEventDetail name=detail.html template=detail.pt class=.detail.DetailEdit permission=cmf.ModifyPortalContent / is fine with /++skin++charlie/@@detail.html Yup, because if you don't specificy a layer explicitly, browser:page / will register a view for IDefaultBrowserLayer. Your charlie skin probably inherits from IDefaultBrowserLayer (either directly or indirectly). That's why this works. Of course, this ties in with what I get from Zope - that the adapter can't be found. I suspect I've misunderstood something fundamental on how views work with layers. My book has a large section devoted to this. :) Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily switch off those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Content types based on Python objects
Charlie Clark wrote: Am 28.11.2007 um 14:03 schrieb Charlie Clark: class Grid(dict, PortalContent) ... TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict Looks like using the old favourite UserDict solve the incompatability problem. class Grid(UserDict, PortalContent): ... Right. You can't mix built-in types with ExtensionClasses (pretty much anything in Zope 2 is an ExtensionClass). Actually, subclassing the built-in types usually only works for trivial cases. UserDict (or PersistentDict) is the right thing to use here. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: eggification status?
yuppie wrote: Wichert Akkerman wrote: A related question is: how do we want to eggify CMF? It seems to make sense to create one egg for the whole of CMF and a second egg for GenericSetup. Why not one egg for each CMF product? Can you please elaborate? *Why* one egg for each product? We'll just end up with the same egg madness that we have with Zope 3 (e.g. zope.app could've just as well stayed one big egg, IMO). It's not like the different parts of the CMF need to move at separate speeds... ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Eggification redux
Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. We badly need it, not only for Zope 3 proper but also for projects which consume Zope 3 eggs (probably Zope 2 in the future, but naturally also grok). +1 to the eggification -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Zope-PAS] Re: Eggification redux
On 25 Sep 2007, at 13:20 , Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. There are several problems. * We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem. * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. * Even with newest=false enabled in grokproject's buildout.cfg template, the versions that people will end up when trying out grok are non-deterministic. This has led to people installing newer versions of something, sometimes even faulty releases, even though Grok hadn't been tested with these newer versions yet and older versions that were known to work were the better choice. Again, a working set problem. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Known working sets II [was: Eggification redux]
(Also CCing zope3-dev where the first known working set discussion started a while ago) Tres Seaver wrote: This is the known good problem. I'm pretty convinced that adding some kind of PyPI subset, where gardeners for a given package set keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the gardened set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. This is certainly an interesting approach. I'd be curious how you would garden this known working set. Martijn makes a pretty good case for maintaining such working sets close to the package in question (e.g. the grok egg, the Plone egg, etc.). I see two more solutions: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF collector on Launchpad?
Jens Vagelpohl wrote: Andreas Jung is in the process of getting the regular Zope 2 issue collector moved onto Launchpad. He said the Launchpad guys could move other collectors like the CMF collector at the same time. The question is, do we want this? My vote is -0.5, mostly because I never used Launchpad. One drawback that was mentioned is the fact that bugtracker emails do not contain the full bug history. From other bugtracker experience I know that's very annoying. Andreas mentioned some arguments for the move, like having the same user base on all those collectors, the ability to move bugs between them, and a much better user interface than the sometimes odd collector UI. In general I'm +1. I agree about the full history in the email, though. Perhaps we can get it at some point if we bug the Launchpad people enough. As far as the user interface is concerned, I actually find the Launchpad one a bit cumbersome at times, too. It's much speedier than our CMFCollector on zope.org, though. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: pdf generation
David Chelimsky wrote: I'm using zope 2.7.8 and looking for a means generating a PDF document. I've googled and looked around a bit but everything seems rather dated (stuff from 2002). That means this stuff is only marginally older than your Zope version ;). What are you all doing to deal with this these days? I've used http://www.reportlab.org with sucess. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: pdf generation
Charlie Clark wrote: Do you know of a Zope Product that already wraps report lab, or do you recommend just accessing directly with a script? I can't think of anything that would do this for you: transforming HTML to PDF doesn't usually work very well. Reportlab is fairly easy to use and extremely fast. Except that it's apparently not thread-safe and should therefore be handled with care. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Moving to browser views
Charlie Clark wrote:
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or should I
use an adapter? The templates are TAL and the only difference to an HTML
page is the different response header.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
to the appropriate call inside a browser view. I haven't been able to
work this out based on the examples or the Zope 3 book.
shameless-plug
You know, I wrote a whole book for learning how to use this Zope 3
stuffm (and that includes explanations of how to use it in Zope 2 via Five).
/shameless-plug
--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
yuppie wrote: Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. setSite() is something that influences the place (= registry) that we look up the utilities from. It doesn't influence the context of the utility because tilities have no context. Sure, utilities might be local and even persistent. But that is a registration detail, not an implementation detail. The name site in Zope 3 is confusing. Place with component registrations is better. So, let's pretend setSite() was called updateCurrentComponentRegistryFromPlace(), it becomes pretty obvious that it has nothing to do with what the utility does. All it does is tell the Component Architecture which component registry to look up things. The fact that this registry happens to be associated with a place in the object hierarchy is completely irrelevant to the Component Architecture. We just don't pass that 'site context' explicitly to the component as in Zope 2. Right. The utility doesn't even *get* the context (and it shouldn't need it.) And in Zope 2 we don't pass the context in either. The tools get it by doing aq_parent(). This should be converted to a lookup, because it's not about the hierarchy that the tool happened to be placed in, it's about getting one very specific object: the CMF site. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. By 'site context' I don't mean an Zope 2 acquisition context or an adapter context. I mean the site specific local environment that is usually looked up based on setSite or provided by CMF tools. Utilities shouldn't care which site context they've been registered at. If they want a specific object like the CMF site they should look it up. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the all tools are utilities now assumption might've been a bit too naive. Of course CMF tool interfaces have some methods we would not add to a new utility interface. But most of them would become views, and as long as we pass in the REQUEST explicitly they are still valid utility methods. I'm not aware of any tool methods that should be converted to site adapters. Most tools use the 'site context' just for the security machinery. The other reason why tools needed the context was looking up other tools, but that is obsolete in CMF 2.1 beta. I consider every other usage of the acquisition context a bug. Good. Then fix those bugs and we no longer need any acquisition wrapping of local utilities at all (and it should be ripped out of five.localsitemanager again). This would, of course, be an acceptable solution. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
yuppie wrote: I'm judging by the solution itself *and* by the fact that we made a decision long ago and released a beta based on that decision. We should reverse that decision only if we are sure it was a mistake. I think it was a mistake. It's ok, we all make mistakes. It's good that we caught it before a final release. Why a mistake? Because some CMF tools were apparently not ready to be looked up as pure Zope 3 utilities yet. They depend on their acquisition context. That's something the Zope 3 CA (deliberately or not) simply doesn't give you. Kapil's also right when he says that utilities by principle are context-less components. the reason why a) was proposed is that the current usage isn't about adopting the zope3 api, its subverting its usage and meaning by introducing context dependencies where there were none before. a utility is context independent, the majority of cmf tools are not. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the all tools are utilities now assumption might've been a bit too naive. On the other hand, there are valid use cases for accessing the site object. Acquisition is only one method here and it happens not to be supported by the Component Architecture. So it seems those tools aren't ready yet, though fortunately the evolution towards a different way of looking up the site object is simple; until then we also have a simple fix (undeprecating getToolByName). instead of introducing implicitness into the zope3 apis that imo defeats the purpose of using them in the first place, we should fix our tools so they can be used with the zope3 api and are not contentspace/context dependent, and till they are so continue to access them as we have been. a clear migration path that adheres to this principle was outline in a). I can see why you want to do it this way around, but I can't see why switching first to utility lookups and changing the implementation later is a mistake. I'm not aware of any problems that can't be resolved by improving the site managers / registries. At this point I don't either. All I know is that you're creating more and more code (and dependencies) just to get getUtility() calls working. Code, as you know, has the tendency to sit around forever. By introducing this Franken-ComponentArchitecture-with-Acquisition system, you'll not only increase the maintenance burden on your part, you'll also taint an API that has been pretty predictable and clear before. I would also bet that the existance of this hybrid will actually slow down the evolvement process, as there will be no apparent reason to refactor tools not to depend on acquisition anymore. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
Sidnei da Silva wrote: On 3/29/07, Tres Seaver [EMAIL PROTECTED] wrote: The cheeseshop shows a pytz-2007d version: http://cheeseshop.python.org/pypi/pytz I was refering to the version included in Zope. That's because we're using a stupid vendor import instead of simply requiring it as an install (same with docutils, btw... at least with twisted we use an external). There are two pytz-related bugs in the Zope 3 bugtracker: - https://bugs.launchpad.net/zope3/+bug/98494 - https://bugs.launchpad.net/zope3/+bug/98495 which were both suspiciously filed on March 13th this year, therefore shortly after the new DST change date. The latter one is about updating pytz... When Zope 3 becomes eggs (we're almost there now), I really really hope we can simply depend on 3rd party packages as eggs... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. I would only be comfortable doing that if we had unit tests for those tools that aren't acquisition-dependent. And by unit test, I mean real unit tests and not a ZopeTestCase. That's the only way we can really be sure that that a tool can function as a utility, an independent component, w/o acquisition. Not knowing the codebase, I suspect that this isn't the case and suggest using getToolByName for all right now and adding such tests to the TODO list for the next CMF release. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Martin Aspeli wrote: We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. +1 The one thing I don't see here explicitly is the forward migration path. Make tools not depend on acquisition and you get can start looking them up using getUtility. This will take time, so I'd be ok if for now we can't use getUtility right away (unless you're willing to do manual __of__ing) I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. At least new stuff can be Zope 3-style already. I suspect that all context-less tools today could be rewritten to be regular global utilities, Absolutely. and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). Well, ideally we'll be able to model containment relationships using __parent__ in Zope 2 as well... However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). I can say from personal experience that deprecating less in more time is easier on the people and on yourself :). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: from Products.CMFCore.interfaces import IWorkflowTool from zope.component import getUtility wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. (Welcome to Acquisition!) Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. getToolByName sounds like a sensible abstraction, don't you think? We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. This is the part of the email I like the most :) It's a bit scary to have to revert the hundreds of changes that have been made to the Plone 3.0 codebase and probably hundreds more to the CMF codebase to move to getUtility, though.
Re: [Zope-CMF] Re: Delete trouble
On 27 Mar 2007, at 20:57 , Dieter Maurer wrote: As so often, we have completely different views on how things should be: When I have an IObjectBeforeDeleteEvent subscriber which should update the unique ID tool, then it can assume that there is indeed a unique ID tool. And if the assumption is wrong, an exception should result. What makes you think you can make that assumption? This is Zope 2 all over again, where things just have to be there. That won't help making things more flexible. We have this situation here: there should be (and is) a unique id tool but the local registrations have not been performed. Nope, we're just not operating in a place where we can get to the tool. It's standard acquisition semantics. An exception is better than silently omit the update of the existing unique id tool. You could argue that the local id tool does not need to be updated as the complete site (including the tool) gets deleted. Indeed. But would the effect be different, if I used: plone_site.some_folder.manage_deleteObjects(). Or in other words, is attribute lookup entailed in traversal? No. If it is not (which I assume), then your defensive programming would hide inconsistencies in the unique id tool -- similar to a defensive try: except: pass. What kind of inconsistencies? We're deleting the thing anyway, what's the point to update it? ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Delete trouble
Martin Aspeli wrote: Philipp von Weitershausen wrote: *sigh* Chapter XYZ in my book explains the process :). Whenever you traverse over a site, its site manager becomes the active component registry. So if you haven't traversed over that site yet, the utilities in that site won't be found. It's that simple. So specifically, when I'm in the root of the ZMI, tick a CMF/Plone site and press Delete, will I be traversing over it or not? Of course not. Your URL doesn't reach as far as the CMF/Plone site. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Delete trouble
Dieter Maurer wrote: Martin Aspeli wrote at 2007-3-25 12:46 +0100: ... I agree, except I think there could potentially be lots of places where this could be happening. In the general case, it's probably safe for that code to assume the utility is there, and treat it as an error if it's not, but during site deletion, it is probably at the mercy of the order of deletions. At least that's my guess. I would not find is a good approach, if exceptions were silently suppressed. Let's look at this closer: - There's probably an event subscriber for IObjectBeforeDeleteEvent on all Plone or CMF objects that makes sure that the deleted item is also purged from the unique ID tool. So far so good. - If that subscriber uses getUtility() calls and doesn't catch a ComponentLookupError, it bluntly assumes that all such content objects must live in an environment that has a unique ID utility. That's asking for a lot (it's almost as bad as simply wanting to be able to acquire portal_uuid or whatever it's called). - To make reuse easier, the suggested pattern is to check if such a utility can be found and then do the unregistering (or even registering when the object is added). If the utility can't be found, then that's too bad but shouldn't impact the actual use of the content type. After all, it's just a dumb content type. This isn't about silently suppressing exceptions, it's defensive programming to increase flexibility. If we know that during deletions exceptional cases could happen, we should inform the component lookup process that we are doing deletions such that it can be less strict in its behaviour. Informing the component lookup process is exactly the queryUtility() call that I meant. It returns None if the component can't be found. In combination for a check if the utility is None or not, this is the less strict behaviour that you're asking for. However, usually the I am going to be deleted event is signalled before the actual deletion takes place. Therefore, the event processing still should find all utilities around. Not if you haven't traversed into site. Then the local utilities won't be found. I suggest reading the chapter on Sites in my book. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. Yes, the ZPublisher should be firing it. But it doesn't. While it's clearly an oversight for Zope 2.10, I wonder if it can be classified as a bug or not. Probably not. Certainly a lot of existing Zope 2 ISites will have this hideous persistent before-traverse hook that came to us via whoever thought of Five.site (*cough* right, Sidnei? :)). So if the ZPublisher introduces this event, we'll ahve to be careful that it won't be sent twice for an object... Patches are welcome :). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Five's local sitemanager, CMF, etc
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and aq-wrapping it back into the context (the
portal root). Without this, we start requiring users of the interface to
know when aq wrapping is needed and do it explicitly with __of__() which
I think we agreed was unacceptably detailed and ugly. :)
Alright, I've gone ahead and put code in place for this (albeit a bit
naively) with r72810. The next question is whether we should be doing
the same with adapters and subscribers as well (even though this
doesn't affect the whole tools-getting-acquired-properly issue).
I'm a bit uneasy about the implementation. With
Acquisition.ImplicitAcquisitionWrapper(base, parent) it seems you're
wrapping all utilities, even those that don't inherit from acquisition
and potentially don't want acquisition. Even worse, you give them an
*implicit* acquisition wrapper.
I think _wrap() should be changed to:
def _wrap(self, comp):
Return an aq wrapped component with the site as the parent.
if Acquisition.interfaces.IAcquirer.providedBy(comp)
parent = Acquisition.aq_parent(self)
if parent is None:
raise ValueError('Not enough context to acquire parent')
base = Acquisition.aq_base(comp)
comp = base.__of__(parent)
return comp
This way, only objects that inherit from one of the Acquisition base
classes will be wrapped at all.
--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Five's local sitemanager, CMF, etc
Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Five's local sitemanager, CMF, etc
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Five's local sitemanager, CMF, etc
On 26 Feb 2007, at 23:48 , Tres Seaver wrote: I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the Zope2 is evil, Zope3 is wonderful fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. Yes. Zope 3 is can be seen as a set of libraries -- and a number of approaches. As far as acquisition (the concept) is concerned, I think the common perception is that Acquisition (the Zope 2 package) introduces pains, magic and unpredictability, whereas the way acquisition is implemented in Zope 3 (discrete places called sites from which you can acquire things after registering things explicitly) is a cleaner and more predictable concept. I see this whole effort (making CMF tools available as utilities, etc.) a way to move from Acquisition (the Zope 2 package) to a better form of acquisition (using the Zope 3 Component Architecture). Such a process needs to be accompanied by clear statements what's encouraged and what's discouraged. That doesn't mean that the old way is evil, but we can certainly give a clear recommandation as to what's better (not necessarily wonderful but better). To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Yes, but their wrapping is a detail of the traversal and security machinery. Hence it happens during traversal, not during component lookup. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a subscription adapter. registry.registerSubscriptionAdapter() More on subscribers vs. subscription adapters: * Subscribers are the event subscribers we know: simple callables. They don't return anything (well, they return None :)), hence there's nothing to wrap or anything. * Subscription adapters are like regular adapters (and they are implemented exactly like a regular adapter). The difference is in the lookup. Instead of getting exactly 0 or 1 adapter in the adaption, you get n adapters (where n=0,1,2,3...) with subscription adapters. Basically, instead of finding the most specific adapter, subscription adapters will return *all* applicable adapters. So their lookup is a bit like the one of subscribers, hence the name. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 9 Feb 2007, at 11:03, yuppie wrote: Taking this into account, how should the five.localsitemanager thing be packaged? Maybe we can use the same pattern as TextIndexNG3: The Python package is shipped in a 'src' subdirectory of the product. The product's __init__ adds 'src' to the sys.path. The code could check if five.localsitemanager already exists (e.g. in a Plone distribution) and modify sys.path only if necessary. This is a hack, but maybe good enough as a temporary solution for CMF 2.1. That's certainly good enough for me. I was about to suggest that: create a pure five.localsitemanager package for the package zealots and make a product that simply puts it on sys.path. I don't think resorting to relative imports is an option. I personally think Python 2's import semantics are pretty much fubared and I can only recommend to always use absolute imports. Also, whatever we create now will have to live under Seaver's law (Persistence means having to say I'm sorry) because five.localsitemanager will obviously have persitent objects (the LocalSiteManager implementation, which is a subclass of PersistentComponents). Anyway, yay on the consensus for CMF 2.1! -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 7 Feb 2007, at 01:58, Philipp von Weitershausen wrote: Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). I won't grace the uncalled-for sarcasm with an answer. Jens, I didn't mean to be sarcastic. Sorry if that came across wrong. You misunderstand my point. I simply don't want the existing dead-simple way of creating quick sandboxes be replaced by some mechanism where I need to start writing configuration files or learn some wondrous framework, just because it's been decreed the technology du jour. I understand and believe it or not, I also sympathize :). The good news is that it's still possible. After all, the initial argument of this thread wasn't that we wanted to eggify or buildoutify CMF, but that we wanted to introduce standard Python packages as possible dependencies. Such packages only have to be on the PYTHONPATH, e.g. put into INSTANCE/lib/python. How they end up there is up to you. As said, symlinking, copying, etc. still works. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Charlie Clark wrote: Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I can see why people would be appalled by easy_install, at least in its default incarnation (inside a workingenv or a zc.buildout it's quite nice). There's little to be afraid for concerning eggs, though. They're just directories with Python packages in them (they often come in a ZIP form and may also be installed that way, which doesn't chagne the fact that they're just directories with Python packages in them). I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. I have no idea what local Products should be, but the Products package contains more magic than anybody should have to handle. The whole reason we have zopectl debug and zopectl test instead of a simple debugzope and test script (like we do have in Zope 3) is that Zope wants an extra special treatment for its Products thing. Doese zopectl work on Windows? No, it doesn't, because it builds on zdaemon. There, Products sucks. If Products were usinig standard Python idioms like namespace packages, etc., we wouldn't have that problem. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. Who says you have to. It seems to me that the only people here complaining are the ones who aren't quite familiar with eggs yet. Also, I seem to detect a general tone of skepticism against the new tools that the greater Python community is building. I can only encourage people to take a look at thigns like workingenv and zc.buildout and at what the Zope and Plone communities have done with these tools. Perhaps they don't allow you to use simple symlinks for deployment, but perhaps they offer something similiar, something even easier and a few additional extra features perhaps? It's worth at least checking these things out. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Martin Aspeli wrote: I don't think eggs/setuptools are perfect. But I don't think they're useless either, and on the whole, so far, they've brought more benefits than problems. By playing with eggs, we're playing better with the rest of the Python community (and things like entry points are very cool). We start being able to re-use some of their tools (workingenv, buildout, paster) and participate more meaningfully by sharing code. In any case, I don't mean this to be acrimonious in any way. I'm justing saying that depending on a non-Products package (be it egg-distributed or not) shouldn't be a problem (because there will only be more and more of these). Good points. To summarize: * eggs aren't the holy grail, but they bring many benefits. * at this point, we shouldn't create artificials hurdles that prevent us from putting new things into packages and hence taking advantages of eggs. Nobody's tearing down old walls, but at least let's not stop building new ones. That's all I can and will say in this matter. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Rocky wrote: On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 5 Feb 2007, at 19:43, Rocky Burt wrote: On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). Not knowing any better I was assuming there'd be a Zope 2-style product, which we could pull in as a SVN external? Hm... well, as long as I avoid absolute imports in five.localsitemanager there's no reason it couldn't be included into a CMF product (perhas CMFCore ?) via svn:externals. Please don't. Relative imports are evil. It's seriously a big wart in Python 2 and will thankfully be fixed in Python 3. Until then I can only recommend absolute imports everywhere. Yes, they're more to type, but at least I've been bitten too often. That's not something I'm particularly fond of but I'm not against it. But as time moves on this is going to become more and more of an issue for CMF (code that isn't expected to live in Products/). Right. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote:
I have now finished (well, finished awaiting feedback and help on one
item) the work on the jens_tools_as_utilities branch.
There's one set of test failures out of
CMFActionIcons/tests/test_exportimport that I can't quite interpret. I
believe it has to do with the way the tests are set up, but I'm not
sure. See traceback below.
You want to register the DefaultTraversable adapter for * (None). I'm
sure other tests in the CMF do this already, it should be easy to adapt
their setup code to that test.
Other than that I have one unrelated failure in the GS tests themselves
and some logger messages coming through, all those smell like test
cleanup issues to me. If I run the GenericSetup tests by themselves I
don't get any failure.
Shrug.
Long live layers to push all the Zope 2 crap into that can't be torn down.
Error in test test_with_icon
(Products.CMFActionIcons.tests.test_exportimport.Test_exportActionIconsTool)
Traceback (most recent call last):
[snip]
File
/usr/local/zope/src/Zope-2.10-branch/lib/python/zope/traversing/adapters.py,
line 161, in traversePathElement
raise TraversalError('No traversable adapter found', obj)
TraversalError: ('No traversable adapter found',
Products.CMFActionIcons.exportimport.ActionIconsToolExportConfigurator
object at 0x3782510)
--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 8 Jan 2007, at 01:19, Hanno Schlichting wrote: Right now I would let all existing CMF tools implement that interface, so we would be on the safe side. In a later release we can revisit this and see if some tools don't need Acquisition to work properly. If I'm not mistaken this should let us remove all the manual AQ- wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that local utilities may need to be local, meaning that they know the place in which they are registered. No they don't. There's nothing implied for local utilities, not even persistence. Of course, many local utilities *are* persistent and stored in a folder somewhere, thus have a __parent__ and all that. But that's typically less of interest when *using* the utility. In Zope2, we *must* wrap them for the sake of security, if nothing else. Sadly yes. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] PersistentComponents is not enough
Philipp von Weitershausen wrote: Jens Vagelpohl wrote: CMF won't come eggified for this release, that work has stalled. whit wrote: plone's egg story looks non-existent until next release. Right, I figued as much. Also, it's only for Zope 2.11 that we can actually tackle sensible egg support in the Zope 2 core, so that makes more sense anyway. I see three options: a) somehow bundle CMF 2.1 (and Plone 3) with a package called five.localsitemanager. Given that Plone 3 already has plone.* packages (and I assume they also want five.customerize), this might probably be less of an issue for Plone than for the CMF. b) make Five 1.6 and have that include five.localsitemanager. I would *rather* not like to do that... c) create Products.FiveLocalSiteManager, or perhaps Products.LocalSiteManager. Yet another product *sigh*. OTOH, that might not be such a problem since I envision products to become eggs in Zope 2.11... Of course, whatever we decide to do, the result really should ship with Zope 2.11. It's already sort of a crime that we don't do this in Zope 2.10 yet. Even worse, Five itself is creating sites w/ PersistentComponents :(. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
Martin Aspeli wrote: Philipp von Weitershausen wrote: Actually, I agree with Dieter here. If something has an __of__(), just wrap it. You can't possibly do anything wrong, actually, as it already happens and it provides the best backward compatibility with what we have right now. Is __of__() in an interface somewhere? I would prefer using that (if it's promised by some mixin deep in zope anyway). Not that it greatly matters, if we actually want a policy that wraps every time. If we want wrapping to be controllable and optional, I think we need a marker interface. Fair enough, __of__() is documented by Acquisition.interfaces.IAcquirer which is provided by all objects inheriting from Aquisition.Explicit or .Implicit. That's your marker interface. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
Hanno Schlichting wrote: Martin Aspeli wrote: Hanno Schlichting wrote: PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Philipp also has some ideas (not too far off completion, I believe) that may remove some of the acquisition intermingling. I'm not sure they'd apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) I still do as I haven't found much time to work on this further. I'm looking for someone to take over my branch (knowledge of Python C API and experience with debugging C code required). I consider this a crucial step in moving forward. Acquisition is really getting in the way now and having the simpler __parent__ API be supported as an alternative in Zope 2 would simplify things a lot -- also in this case. Alas, I'm running out of time and experience with this stuff. :( -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Fwd: [Checkins] SVN: CMF/branches/1.6/C CMFCore.DynamicType: Fixed behaviour regarding default view.
Stefan H. Holek wrote: CMF 1.6 is supposed to work with Zope 2.8. Aha. Yuck. :) However, either there is no queryDefaultViewName or it lives someplace else... from zope.app.publisher.browser import queryDefaultViewName ImportError: cannot import name queryDefaultViewName All fixed now... -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] How to run CMFCore 2.0 tests?
Hi there, while forward-porting the fix for http://www.zope.org/Collectors/CMF/459 from 1.6 to 2.0, I was running the tests for CMFCore 2.0 and was getting tons of failures with a straight checkout (see attached file). Is there anythign I'm missing? Philipp -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! $ bin/zopectl test -s Products.CMFCore Running tests via: /opt/local/bin/python /usr/local/Zope-2.9.6/bin/test.py -v --config-file .../etc/zope.conf -s Products.CMFCore Parsing .../etc/zope.conf Running tests at level 1 Running unit tests: Running: Error in test test_normal (Products.CMFCore.exportimport.tests.test_catalog.exportCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' . Error in test test_unchanged (Products.CMFCore.exportimport.tests.test_catalog.exportCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' . Error in test test_empty_purge (Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' . Error in test test_empty_update (Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' . Error in test test_normal_purge (Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' . Error in test test_normal_update (Products.CMFCore.exportimport.tests.test_catalog.importCatalogToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 86, in __call__ self.setUp() File .../Products/CMFCore/exportimport/tests/test_catalog.py, line 110, in setUp Products.GenericSetup.PluginIndexes) AttributeError: 'module' object has no attribute 'PluginIndexes' .2006-12-07 23:06:41 WARNING ZODB.DB DB.open() has 8 open connections with a pool_size of 7 . Error in test test_body_set (Products.CMFCore.exportimport.tests.test_skins.SkinsToolXMLAdapterTests) Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py, line 260, in run testMethod() File .../Products/GenericSetup/testing.py, line 98, in test_body_set adapted.body = self._BODY File .../Products/GenericSetup/utils.py, line 515, in _importBody self._importNode(dom.documentElement) File .../Products/CMFCore/exportimport/skins.py, line 106, in _importNode self._initObjects(node) File .../Products/GenericSetup/utils.py, line 574, in _initObjects raise ValueError(unknown meta_type '%s' % meta_type) ValueError: unknown meta_type 'Filesystem Directory View' ... Error in test test_fragment3_skip_purge (Products.CMFCore.exportimport.tests.test_skins.importSkinsToolTests) Traceback (most recent call last): File /usr/local/Zope-2.9.6/lib/python/Testing/ZopeTestCase/profiler.py, line 98, in __call__ testMethod() File .../Products/CMFCore/exportimport/tests/test_skins.py, line 557, in test_fragment3_skip_purge importSkinsTool(context) File .../Products/CMFCore/exportimport/skins.py, line 213, in importSkinsTool importObjects(tool, '', context) File .../Products/GenericSetup/utils.py, line 754, in importObjects importer.body = body File .../Products/GenericSetup/utils.py, line 515, in _importBody
[Zope-CMF] Re: How to run CMFCore 2.0 tests?
Jens Vagelpohl wrote: P.S.: This problem does not occur on the trunk. I'll blame Yvo for the clean run on the trunk ;) Yes, I was quite (positively) baffled by how nicely the tests run on CMF, using layers and all that. Kudos to Yvo! -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] writing tests for CMF 2.1
yuppie wrote: Since CMF 2.0 I did a lot of test refactoring, changing the ways CMF tests are set up. Goal was to use more generic and up to date testing patterns, making it easier to write new tests. Here is an overview what changed: ZopeTestCase.app() -- All tests that depend on a running Zope application use now ZopeTestCase's ZopeLite app. It is not compatible with Zope2.app(), so don't use Zope2.app() anymore. ZopeLite doesn't start up Products by default, you have to specify required Products explicitly using ZopeTestCase.installProduct(). Not each Product has to be initialized that way. Don't initialize Five that way - ZCML is set up differently. Layers -- ZCML is set up using test layers. Their setUp() and tearDown() methods are only run once for all tests in the layer. Who! -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Effective use of effective_date and expiration_date
Raphael Ritz wrote:
Tres Seaver schrieb:
[..]
Yep -- this is how the typical site uses those dates. However, some
folks want actual workflow transitions to happen ASAP after each date
passes. In that case, you need to write a periodic task which searches
for objects which are in the between state (e.g., their expiration
date has passed but they are still active), and cause the workflow
tool to tickle the transition machinery. E.g., as a Python Script::
# untested
for brain in context.portal_catalog.searchResults(
review_state=published,
expiration_date={'query': ZopeTime(),
'operator': 'max'}):
obj = brain.getObject()
wf_tool.doActionFor(ob, 'expire')
Yep. And just reinforcing the obvious:
Trigger the script Tres mentioned on a regular basis
yourself, either using a cron job or Zope's ClockServer
from Chris (included in Zope 2.10 now?)
http://plope.com/software/ClockServer/
Yup, included.
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF tests failing in zope 2.10
Florent Guillaume wrote:
Some CMF 1.6 and 2.0 (and I guess trunk) tests are failing in Zope 2.10
due to missing adapters somewhere. Example, when it tries to evaluate
the path 'info/id' (where info is a dict):
Error in test test_generateWorkflowXML_multiple
(Products.DCWorkflow.tests.test_exportimport.WorkflowDefinitionConfiguratorTests)
Traceback (most recent call last):
...
File
/Users/fg/zope/zope2-zope/lib/python/Products/PageTemplates/Expressions.py,
line 121, in _eval
ob = self._subexprs[-1](econtext)
File /Users/fg/zope/zope2-zope/lib/python/zope/tales/expressions.py,
line 124, in _eval
ob = self._traverser(ob, element, econtext)
File
/Users/fg/zope/zope2-zope/lib/python/Products/PageTemplates/Expressions.py,
line 73, in boboAwareZopeTraverse
request=request)
File
/Users/fg/zope/zope2-zope/lib/python/zope/traversing/adapters.py, line
161, in traversePathElement
raise TraversalError('No traversable adapter found', obj)
TraversalError: ('No traversable adapter found', {'state_variable':
'state', 'state_info': [...], ...})
Does anyone have an idea which adapters are missing, and where to add
them in the tests?
Yup. I bet you just need to do
zope.component.provideAdapter(zope.traversing.adapters.DefaultTraversable).
The Zope 3 page template engine will use ITraversable adapters to
traverse just about anything. So, basically, wherever you're employing a
page template in CMF tests, you'll want this adapter.
Philipp
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup now incompatible with Zope 2.8?
yuppie wrote: Jens Vagelpohl wrote: This checkin seems to have broken Zope 2.8-compatibility: http://svn.zope.org/GenericSetup/trunk/tests/common.py?rev=68391r1=41338r2=68391 Specifically, the line from zope.testing.cleanup import cleanUp breaks Zope 2.8, I checked all stable tags (2.8.5, 2.8.6, 2.8.7) and there is no toplevel name cleanUp in zope.testing.cleanup. DEPENDENCIES.txt still claims it works with Zope 2.8.5 and higher. One or the other needs changing, either DEPENDENCIES.txt needs updating or, if this breakage was inadvertently introduced, common.py needs fixing. Sorry, my mistake. I only tested against Zope 2.9 and 2.10 before checking in. Should be fixed now: http://svn.zope.org/?rev=68474view=rev Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should instead do the following (which works across all Zopes): from zope.testing.cleanup import CleanUp CleanUp().cleanUp() ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: SVN: CMF/trunk/CMFCore/ - fixed the unit tests that failed on Zope 2.10
Yvo Schubbe wrote: Log message for revision 68396: - fixed the unit tests that failed on Zope 2.10 (There is still one error, but that seems to be caused by a Zope bug.) Please file collector entries so that we know and eventually fix them. +class Expression(Persistent): security = ClassSecurityInfo() def __init__(self, text): self.text = text -self._v_compiled = getEngine().compile(text) +if text: +self._v_compiled = getEngine().compile(text) May I suggest to make this test more robust for superfluous whitespace?: if test.strip(): self._v_compiled = getEngine().compile(text) def __call__(self, econtext): +if not self.text: +return '' Same here... Modified: CMF/trunk/CMFCore/tests/test_Expression.py === --- CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:10:52 UTC (rev 68395) +++ CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:18:49 UTC (rev 68396) @@ -49,21 +49,34 @@ def test_anonymous_ec(self): self.portal.portal_membership = DummyMembershipTool() ec = createExprContext(self.folder, self.portal, self.object) -member = ec.global_vars['member'] +if hasattr(ec, 'contexts'): +member = ec.contexts['member'] +else: +# BBB: for Zope 2.9 +member = ec.global_vars['member'] Please file a collector issue for this BBB problem. Thanks Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: SVN: CMF/trunk/CMFCore/ - fixed the unit tests that failed on Zope 2.10
yuppie wrote: Philipp von Weitershausen wrote: Log message for revision 68396: - fixed the unit tests that failed on Zope 2.10 (There is still one error, but that seems to be caused by a Zope bug.) Please file collector entries so that we know and eventually fix them. Tres did that already: http://www.zope.org/Collectors/Zope/2117 Excellent. Modified: CMF/trunk/CMFCore/tests/test_Expression.py === --- CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:10:52 UTC (rev 68395) +++ CMF/trunk/CMFCore/tests/test_Expression.py2006-05-30 16:18:49 UTC (rev 68396) @@ -49,21 +49,34 @@ def test_anonymous_ec(self): self.portal.portal_membership = DummyMembershipTool() ec = createExprContext(self.folder, self.portal, self.object) -member = ec.global_vars['member'] +if hasattr(ec, 'contexts'): +member = ec.contexts['member'] +else: +# BBB: for Zope 2.9 +member = ec.global_vars['member'] Please file a collector issue for this BBB problem. I don't think this BBB issue has to be resolved in Zope. AFAICS global_vars is not part of the API and CMF used it just for unit test hacks. Just looked at the code. You're right. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: How do deal with cmfcatalog-wrapped objects?
yuppie wrote:
Andreas Jung wrote:
we have a CMF-based application where I am trying to migrate from
TextIndexNG 2 - 3.
For a content-type class A I have configured an adapter to implement
IIndexableContent. However when the object is reindexed CMF wraps
the object as IndexableObjectWrapper which by itself implements
the IndexableObjectWrapper interface. The low-level indexer of TXNG
get the wrapped object and has no idea what to do with the object
since the interface of the wrapper shadows the interface of the
wrapped object.
Any idea how to deal with this problem?
I'm currently fighting with the same issue. And I was in the process of
writing a mail to the Zope-CMF list when your mail came in. AFAICS this
is more a CMF issue than a Five issue, so I add Zope-CMF to the
recipients list.
Just for the records, I'm sure you already figured that out yourself:
Plone 2.1 doesn't have this issue because it has no interface
declaration on its ExtensibleIndexableObjectWrapper. If the wrapper
doesn't have its own __providedBy__ attribute the __getattr__ method
looks it up in the wrapped class, making the interface declarations
completely transparent.
Plone 2.5 has an interface declaration so I guess it has the same
problem as the CMF.
The quick and dirty solution would be to remove the interface
declaration from the wrapper. The clean solution would be to make sure
that all the interfaces that are actually provided - the wrapper
interface *and* the interfaces of the wrapped object - can be looked up.
But implementing that seems to require deeper knowledge of the interface
machinery than I have.
This problem has already been solved in Zope 3. There we like to wrap
objects that don't provide ILocation (__parent__ and __name__
attributes) in something that *does* provide ILocation. The resulting
object is a proxy for the original object and in addition that it
provides __parent__ and __name__ attributes. The proxy provides whatever
the original object provides plus ILocation.
We call this concept a /decorator/. This is not to be confused with
Python 2.4's function decorators. In Zope 3's case, think of decorator
as a proxy that also adds stuff to the object (e.g. the ILocation API).
Hence, it decorates the original object, like a Christmas tree if you will.
There are two options:
1. I think for the long term, IndexableObjectWrapper could be made a
decorator. This works as follows:
from zope.proxy import getProxiedObject
from zope.app.decorator import Decorator
class IndexableObjectWrapper(Decorator):
def allowedRolesAndUsers(self):
ob = getProxiedObject(self)
allowed = {}
for r in rolesForPermissionOn(View, ob):
allowed[r] = 1
localroles = _mergedLocalRoles(ob)
for user, roles in localroles.items():
for role in roles:
if allowed.has_key(role):
allowed['user:' + user] = 1
if allowed.has_key('Owner'):
del allowed['Owner']
return list(allowed.keys())
2. In the short term we can apply the following trick
(IndexableObjectWrapper needs to be a new style class!):
from zope.interface import providedBy
from zope.interface.declarations import ObjectSpecificationDescriptor
from zope.interface.declarations import getObjectSpecification
from zope.interface.declarations import ObjectSpecification
class IndexableObjectSpecification(ObjectSpecificationDescriptor):
def __get__(self, inst, cls=None):
if inst is None:
return getObjectSpecification(cls)
else:
provided = providedBy(inst.__ob)
cls = type(inst)
return ObjectSpecification(provided, cls)
class IndexableObjectWrapper(object): # new-style!
implements(...) # it can implement as much as it wants
__providedBy__ = IndexableObjectSpecification()
...
This is obviously untested, but I'm pretty confident that this would work.
Philipp
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Tres Seaver wrote: I'm not sure what Chris meant, but the change to the visual output of the testrunner when running with dots seems gratuitous to me, as well -- I don't see any benefit to the indented, narrower output, Me neither, for what it's worth. Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. Sort of. It didn't break configure make. It's just make install that was broken. I still don't understand why people whine about make install being gone. The point of a checkout is that you have a full functional SVN working copy, not an installation source. If you want to install things, use a TGZ archive which lets you do make install perfectly fine. I've never installed Zope anywhere except on production servers anyway, and there you should obviously use releases. If you absolutely must use make install from a checkout (perhaps because you want to install the trunk somewhere), then you can make a TGZ first using zpkg. Though I still don't see the point of it. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] CMF 2.0 browser views and Five traversal
yuppie wrote: Based on the discussion on the Five list I propose this solution: 1.) To become independent of the lookup order views are named different than the corresponding skin methods. 2.) Skins *and* views are always enabled. 3.) A new extension profile hooks up the views instead of the skin methods. This seems like an elegant solution. Enabling Five traversal and views by default is a big change so we might need an other beta release. I would strongly suggest that. Some details: - I'd like to keep the changes the extension profile makes as small as possible. So I don't want to change the visible action targets. All we need are some Method Aliases that point to the views. - We need new names for the views. I'd like to use @@view.html, @@edit.html and @@properties.html for the views that already exist. +1 for saner view names. document_view or document_edit_form is just a lame legacy from the one flat view namespace that portal_skins provide. By the way, unless you make @@view.html the default view name for documents or whatever (using five:defaultViewable and browser:defaultView), why not call it @@index.html?? Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martin Aspeli wrote: From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over 2.8. Below you are suggesting that Plone 2.5 should do the same with Zope 2.8 (favouring it over 2.9). I don't understand why that should be. If one version has to be favoured at all, it should be the most recent one. That way it's made clear that the lower version (2.7, 2.8) is only still supported as a courtesy for those who don't want to upgrade right now. All other Plone developers and users should preferrably use the highest stable of Zope, otherwise Plone will continue to lag behind at least one Zope major release. I'm not the release manager, so it's not my decision, but I think the argument goes something like, Zope 2.9 hasn't lived very long, and .0 versions of Zope have a history of having subtle security and performance bugs; similarly, those who just upgraded to Zope 2.8 may not want to upgrade again just yet. 2.8 is the conservative choice, for those who want the most stable, out-of-the-box Plone. 2.9 will likely be the choice for those who want the latest and greatest features from add-on products. Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... We will have to get used to the fact that Zope 2 release lines live shorter. They live for one year, to be exact. I think conservativism shouldn't extend beyond the age of Zope releases, unless the Plone people want to continue to maintain and release older Zope 2 versions on their own time. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Andrew Veitch wrote: Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... Just so I'm clear, I've just checked the Plone 2.5 roadmap and it says it is due in 8 May this year - is it really true that Zope 2.8 is going to stop getting bugfixes in June this year? Yes. This was suggested by the Zope 2 release manager, Andreas Jung, two months ago: http://mail.zope.org/pipermail/zope-dev/2005-October/025554.html. Of course, other people are still welcome to backport fixes to the 2.8 branch and make releases themselves, but I suspect neither Andreas nor the Zope 2 developers will have the bandwidth to maintain more than three concurrent branches (Zope 2.9, Zope 2.10 and the trunk at that time). I think for those of us deploying Zope on an enterprise scale it will be pretty hard to do upgrades this frequently. I think one year is a pretty big span. Today, for example, you would not start a project on Zope 2.8. You would do it with Zope 2.9 which is going to get bugfixes until the end of 2006. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Alexander Limi wrote: From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over 2.8. Below you are suggesting that Plone 2.5 should do the same with Zope 2.8 (favouring it over 2.9). I don't understand why that should be. If one version has to be favoured at all, it should be the most recent one. That way it's made clear that the lower version (2.7, 2.8) is only still supported as a courtesy for those who don't want to upgrade right now. All other Plone developers and users should preferrably use the highest stable of Zope, otherwise Plone will continue to lag behind at least one Zope major release. Well, this depends on what release ships when. We made a decision not to ship Zope 2.8.0 as the standard in the installers when shipping Plone 2.1 - and that turned out to be a good choice, based on the number of problems it had. I can guarantee you that Plone 2.5 will not ship with a Zope 2.9.0. A Zope 2.9.(1|2|3) might be possible, but there's no way we are shipping a .0 release of Zope with Plone. Once burnt, twice shy. :) There are indeed some issues to be sorted out with Zope 2.9 (Windows installer, premature zLOG deprecation, etc.), all of which aren't too big anymore, though. I think we can and should have a 2.9.1 bugfix release relatively soon. By looking at http://plone.org/products/plone/roadmap, Plone 2.5 will be out by 2006/05/08. By then Zope 2.9 can be considered stable and shippable I would say. Heck, by that time we'll already have a 2.10beta if I'm not mistaken. That and make the upgrade from Zope 2.7/2.8 to 2.9 flawless as well as make 2.9 the *recommended* version for Plone 2.5. Then I don't think it should be much of a problem for Rocky to not have this available in 2.8, except perhaps if he wants to get started right now, with Plone 2.1 (though that might still run under Zope 2.9 and CMF 1.6, I hope). What we ship in installers is one thing, what we personally use and recommend is another. The installers will always be more conservative when choosing versions. I can understand that reasoning. Fortunately, time-based releases will let us schedule these things in advance. E.g. by looking at the Plone 3.0 roadmap we can say that it will be relatively safe for it to depend and ship with Zope 2.10, coming out more than 3 months after the Zope 2.10 final release. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: In an earlier thread I argued that this modified version of Five 1.2 should perhaps get a new name to indicate the additional feature. Do you all think that this would be feasible, or should we just go on with 1.2.1? If we give it a new name, the question is obviously which. 1.3 is already taken so we need some sort of suffix (a letter perhaps). Suggestions are welcome :). Ugh, soon we'll get Five 1.2-RC3-beta5-whatever. :) Hehe. Are we really sure a further Five feature release for Zope 2.8 is actually needed? What's happening with CMF and Plone in this regard? Is Plone 2.5 still targeting Zope 2.8? Yes. Is CMF? CMF 1.6 is. I hope CMF 2.0 is not. I heard some mumblings perhaps 2.9 should be targetted. But perhaps Zope 2.8 is still solidly the target. Perhaps these use cases aren't driven by Plone/CMF core and some other packages would like to use this in Zope 2.8? Can they be identified? The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. For simplicity, both for the developers using Five as well as for the developers building Five, it'd be much easier if we could simply all agree new features go into Five 1.4 for Zope 2.9. Yes. I agree. I guess the only compelling reason to backport to Five 1.2 is to make people NOT upgrade to Zope 2.9 for this particular feature (product-less packages). Then again, Zope 2.9 is stable (people don't really trust a .0 release) and we could release Five 1.4 any time after Rocky is done. So there's really no reason for people NOT to upgrade, I guess. Then again, I'm not absolutely against continuing the Five 1.2 line with new features. Me neither. How to name it is indeed tricky. Perhaps in favor of comprehensibility we just want to name it 1.2.1, even though we add new features. While we cheat and add new features to what should be a pure bugfix release, potentially destabilizing it, I think it's easier on everyone's mind not to introduce a new line of Five 1.2's with features. Yes, on second thought I agree. I also still hope that the pressure to add new features to Five 1.2 will go away very quickly. Well, in five months we can retire Five 1.0 and 1.2 for good. I do not plan to maintain Five releases any longer than their corresponding Zope releases (others are welcome to do that, of course). Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Tim Hicks wrote: The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. You can turn that around; for consistency of installation experience in Zope 2.8, it's important that people don't get a new way of installing products, confusing innocent individuals installing Zope software. For the cutting edge, Zope 2.9, that argument is slightly different. Coming at this with a zope 2 head on, it seems to me that it might be nice if I could carry on using the Products directory so that when I add new 'products', I don't have to mix them in with the core zope code in lib/python/. What do you mean by core zope code? Zope lives in SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your own python packages live in INSTANCE_HOME/lib/python, e.g. /var/zope/foobar.com/lib/python. But the separation of 'core' and 'extras' gives me a comfortable feeling. Is it just me? Am I just stuck in the past? I think you're just confusing software home vs. instance home. We're not making you put stuff into software home (although you can if you really want to... you can even put stuff into site-packages or anywhere you want as long as it's in PYTHONPATH). Plus, just the fact that stuff *being* somewhere in the PYTHONPATH doesn't mean it gets loaded. You have to add a ZCML slug to INSTANCE_HOME/etc/package-includes first. So, you could install a package globally and just make it available to certain instances by placing a slug or not. This is how package deployment works in Zope 3 and it's where we're heading with Zope 2 as well. See http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos for further info and some ranting as well as constructive suggestions. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | Then again, Zope 2.9 is stable (people don't really trust a .0 | release) and we could release Five 1.4 any time after Rocky is done. So | there's really no reason for people NOT to upgrade, I guess. There is at least one reason: People running python2.3 must switch to python2.4 for Zope 2.9. That's somewhat painful, at least on Windows. AFAIK installing multiple Python versions on Windows isn't a problem. Plus, doesn't Zope 2 ship with its own Python anyways? I don't recall if OS X comes with Python 2.4 by default. Tiger ships with Python 2.3.5. However, compiling Python 2.4 from source is a piece of cake, let alone fink, darwinports or gentoo portage which provide the same kind of packaging capabilities to OSX as they do to Linux/Unix distributions. I haven't met a single developer who uses OSX and doesn't use at least one of those. And there's also MacPython which is a pointy-clicky installer for OSX; it's also available for Python 2.4, IIRC. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: Is Plone 2.5 still targeting Zope 2.8? Yes. Yes to which question? Yes to Is Plone 2.5 still targeting Zope 2.8. Perhaps these use cases aren't driven by Plone/CMF core and some other packages would like to use this in Zope 2.8? Can they be identified? The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). I know what the modifications allow you to do. It's a fundamentally different way of developing and installing products. Therefore it's good to ask why we would want to expose such a fundamentally new feature for Zope 2.8. Do we really want to start explaining to people that My product is special, you need to install it like this, unlike what you're used to when what we're dealing with is not even the most recent stable release of Zope? To be clear: I realize that this effort is to make things *less* special for Zope on the long term, and I support it's overall it with some reservations, but we have to think about the tactical short term too. Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... As somebody who's somewhat involved in Zope documentation, I am one of those above mentioned people. For how long do we intend to evolve new features for what is not the most recent stable release of Zope? I.e. we can make the argument that this should be in the hands of the people soon for just about any new feature in Five. Good point. How urgent is it that all of this works with Zope 2.8? I guess it's urgent if you want to sell it to the Plone community, which will only switch to Zope 2.9 or beyond by next year or so, I expect. How much more often is this kind of thing therefore going to happen? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. You can turn that around; for consistency of installation experience in Zope 2.8, it's important that people don't get a new way of installing products, confusing innocent individuals installing Zope software. For the cutting edge, Zope 2.9, that argument is slightly different. I want to identify the reasons why it is so important that this change happens with Zope 2.8. The main reason I can identify is Plone, correct? I let Rocky take this one. I don't really feel strongly about having this available in Zope 2.8. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: | Sidnei da Silva wrote: | On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | | Then again, Zope 2.9 is stable (people don't really trust a .0 | | release) and we could release Five 1.4 any time after Rocky is done. So | | there's really no reason for people NOT to upgrade, I guess. | | There is at least one reason: People running python2.3 must switch to | python2.4 for Zope 2.9. That's somewhat painful, at least on | Windows. | | AFAIK installing multiple Python versions on Windows isn't a problem. | Plus, doesn't Zope 2 ship with its own Python anyways? Yes, the issue is not installing python, but packaging Zope. People building installers for Windows have to have a MSVC 7 and there might be a significant amount of work involved on making all dependencies of those installers work on Python2.4. True. Good point. But for how long do these people (I assume Enfold is one of them) plan to stick with Zope 2.8 then? I mean, they have to move forward at *some* point. Sure, it won't happen over night, but neither will Products-less packages in Zope 2... Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Head-slot in five_template
Lennart Regebro wrote: CMF 1.5 and 1.6 five_template (the one that provides a bridge between zope3 and CMF templates) doesn't have a head-slot. I'm just wondering if that slot is somewhat standard in Zope3 and CMF and not only CPS, becuse it it is I'll add it. So? Is it? Zope 3's Rotterdam and Boston have: - title (on title /) - headers (additional headers in head /) - body(main content in a div /) ZopeTop also has a 'head' slot for the whole head / element. Zope 3 style views in Five should use the same slots as they would in Zope 3, IMO. That means five_template would have to translate between Zope 3 slot names and CMF slot names. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Removing default from browser:skin layers?
Tres Seaver wrote:
The error I am seeing is early, during product initialization, before
any tests are actually running:
File
/home/tseaver/projects/Zope-CVS/Zope-SVN-trunk/lib/python/zope/configuration/config.py,
line 1390, in toargs
args[str(name)] = field.fromUnicode(s)
File
/home/tseaver/projects/Zope-CVS/Zope-SVN-trunk/lib/python/zope/configuration/fields.py,
line 231, in fromUnicode
raise InvalidToken(%s in %s % (v, u))
ZopeXMLConfigurationError: File
/home/tseaver/projects/CMF/cmf_test/z29_cmfhead/Products/CMFDefault/configure.zcml,
line 5.2-7.6
ZopeXMLConfigurationError: File
/home/tseaver/projects/CMF/cmf_test/z29_cmfhead/Products/CMFDefault/skin/configure.zcml,
line 11.2-14.8
ConfigurationError: ('Invalid value for', 'layers', Couldn't import
default, No module named default in cmf default)
2005-11-15 14:05:11 ERROR Zope Couldn't install Five
That line in CMFDefault/skin/configure.zcml does:
!-- 'default' layer breaks when run under 2.9! --
browser:skin
name=cmf
layers=cmf default
/
For the mailinglist archive:
This was a problem in Five 1.3b and 1.3b2. The 'default' layer wasn't
properly registered when Five was ported to Zope 3.2. This has been
fixed in Five 1.3b3 and the Zope 2.9 branch.
Philipp
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Removing default from browser:skin layers?
Tres Seaver wrote: Brent Hendricks wrote: Tres, I'm having trouble with the change you made today taking 'default' out of the list of layers for the cmf browser:skin in CMFDefault/skin/configure.zcml. It seems to cause the views we'e defined in CMFPlone to no longer be found via the context/@@ lookup in page templates. I added layer=cmf to all of the plone view declarations, but that didn't seem to work. Do you any ideas? In the meantime I defined a 'plone' skin that adds default back in, but I'd prefer not to do that if it's not supported. Likely my bad; its presence was causing test breakage when running on 2.9, so I removed it, intending to investigate why. Let's put it back, with a note in the ZCML documenting the fact that it needs to be checked out. Any skin that wants to take advantage of all the elementary browser views (such as absolute_url, standard_macros, etc.) should include the 'default' layer because that's what all these views are registered for. Registering the Plone views for the 'default' layer is perfectly fine; in Zope 3 you don't need to create new layers for new packages because layers can be used across packages (unlike in the CMF). In my experience, Zope 3 layers are usually only used what they were made for: to customize existing views, IOW, to customize views in the 'default' layer. Tres, if you're experiencing the test failures with the Zope 2 trunk but not with Zope 2.8 branch, it might be because your stub request is lacking the 'default' layer. In Zope 3.1+, layers and skins are interfaces extending IBrowserRequest and they are directly provided on the request object by the skin machinery. Five tricks the Zope 2 request into providing the correct default skin interfaces with the following code in Traversable.__bobo_traverse__(): from zope.app.publication.browser import setDefaultSkin from zope.app.interface import queryType [snip] # set the default skin on the request if it doesn't have any # layers set on it yet if queryType(REQUEST, ILayer) is None: setDefaultSkin(REQUEST) In order to do deal with this (e.g. in tests) in both Zope 2.8 and 2.9 without resorting to ugly try/except clauses, Five could maybe grow a convenience function to do the above. It would do nothing in Five 1.2 and the above in 1.3. It would go away for Five 1.5. Let me know if this is the case, I'll be happy to put the function into Five and release new betas of 1.2 and 1.3. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
