Re: [Zope3-Users] Re: Applying permissions to users from LDAP
On 2/13/07, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 13 February 2007 04:51, David Johnson wrote: I'm trying to understand this situation also since we face it frequently. The PAU has a Group Folder which works well in this regard. Would the idea of extending Groups in the PAU to include any person in the ldap directory be useful? It seems this would be easier and more flexible. That's what I would do. I think LDAP permissions/roles/groups map best to our concept of groups. To implement a group folder that gets its groups from LDAP should not be that hard, given the existing ldappas implementation. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training Hi All, Thanks to all your excellent advice, I have gone ahead and extended the existing Group folder to automatically import and periodically synchronize it's groups with an LDAP directory. The functionality is currently a bit crude, but it gets the job done. I'm talking to my employer about open sourcing it, would anyone here be interested in it? Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Applying permissions to users from LDAP
Thanks Philipp! I suspect your first suggested solution will probably be the one that makes sense for us, but I will have to do a little experimentation to be sure. It's very useful that you are able to actually pick out the interfaces and interface methods that are of concern to me. This reminds me that I have to pick up the new version of your book. Alec On 2/9/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Alec Munro wrote: I've just succeeded in getting Zope authenticating against my LDAP directory, using ldapadapter and ldappas. The directory itself is brand new, and is currently only being used for Zope. I am able to manually grant permissions to LDAP users, but I'm wondering if there's a way to automatically grant an LDAP user certain roles, depending on what groups he or she is in? I imagine this could probably be done by extending ldappas, but it seems like a common problem, so I thought it would be worth asking here to see if anyone has any other ideas (or has already extended ldappas themselves). Alec, roles are a concept only known to Zope 3's default security policy, they aren't really a part of the authentication system. While the authentication only identifies principals according by matching login credentials to a user database, the security policy actually decides whether a principal has a certain permission or not (IInteraction.checkPermission). Zope's default security policy happens to use an intermediary concept between principals and permissions called role. The default policy retrieves the roles and permissions of a principal by adapting the current context object to IPrincipalRoleMap or IPrincipalPermissionMap, respectively (from zope.app.securitypolicy.interfaces). The default adapters for these store the maps persistently in annotations. The Grant view uses the same adapters to persistently modify this information. So, if you want your LDAP users to automatically have certain roles or permissions, one way to go would be to implement custom IPrincipalRoleMap or IPrincipalPermissionMap adapters. This would be a way to adjust the behaviour of the existing default security policy. Another solution for your problem might be a custom security policy (perhaps based on Zope's default one) that inherently knows about which principals get which permissions / roles automatically. This coudl also be made pluggable so that you wouldn't have to write a new security policy every time those sets of permissions and roles change. From a brief look, it seems that this is what the crowd concept of schooltool.securitypolicy (http://source.schooltool.org/svn/trunk/schooltool/src/schooltool/securitypolicy/README.txt) seems to solve. It should be quite trivial to write an LDAP crowd (representing all principals from the LDAP database) and then grant that crowd the specified permissions. HTH -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Applying permissions to users from LDAP
Hi List, I've just succeeded in getting Zope authenticating against my LDAP directory, using ldapadapter and ldappas. The directory itself is brand new, and is currently only being used for Zope. I am able to manually grant permissions to LDAP users, but I'm wondering if there's a way to automatically grant an LDAP user certain roles, depending on what groups he or she is in? I imagine this could probably be done by extending ldappas, but it seems like a common problem, so I thought it would be worth asking here to see if anyone has any other ideas (or has already extended ldappas themselves). Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Zope 3 PAM or /etc/passwd authentication?
Hi List, I'm wondering if anyone knows of a way to integrate Zope with /etc/passwd? PAM was suggested, but I don't know too much about that. I suppose I could probably write my own, but I would prefer to avoid that if possible. Anyone have any experience with this? It seems like it's probably a fairly common requirement. Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Good event policy for operating on object hierarchies?
Hi List, I have an object hierarchy that I import from certain ODT files, and I would like to determine the best way to handle events for importing this hierarchy. Does it make sense to fire one create event for the entire operation, for attaching the hierarchy to the existing object structure, or should I attach the root of the new hierarchy first, fire an event for that, and then repeat the process on it's descendants? I don't make particular use of events currently, but if there's any best practices for this type of procedure, I would rather follow those. Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Intended scope of viewlets?
Thanks again. I think I understand why I was having difficulty with this. It seems that under this model, views are tied directly to skins, and if you wish to change skins, you change the template registration, and probably some CSS resource registrations, rather than simply specifying another skin using ++skin++. I suppose, however, that I could create a lower level layer that I did all of my skin-independent view registrations on. I think I will try to write up all of my experiences with viewlets and post it somewhere, as it seems like they are very powerful once you can understand how to properly separate concerns with them. Alec On 10/10/06, Jürgen Kartnaller [EMAIL PROTECTED] wrote: Hi Alec. Alec Munro wrote: One more thing. When using this masterpage idea, what is the pattern for creating new pages? For example, I would traditionally have: MyObject/SubjectOne.html MyObject/SubjectTwo.html MyObject/SubjectThree.html Registered with: page for=IMyObject name=SubjectOne.html template=subjectone.pt / ... Where subjectone.pt would probably start with something like the following: html metal:use-macro=views/standard_macros/view Obviously, the above no longer applies, so what's the equivalent? My initial thought, if I am sticking as close to the above paradigm as possible, would be to have registrations for each that all reference the same class, being the one that implements the interface my masterpage is registered for. Something like the following: page for=IMyObject name=SubjectOne.html class=.MySkin.SimplePage / page for=IMyObject name=SubjectTwo.html class=.MySkin.SimplePage / ... In some ways, this makes sense to me, but it leaves me unsure how to properly differentiate the content on each page, without implementing something on each ViewletManager that detects the name of the page requested, and returns the appropriate content. Unless of course I can register Viewlets or ViewletManagers to specific page names? Thats what the view parameter in the viewlet directive is doing :) My guess is that the above pattern simply isn't applicable to the use of viewlets, and there is something else I should be using. I will investigate uses of viewlets, but if anyone knows the answer offhand, I would very much appreciate it. Simply derive a new view class from SimplePage and use that class when registering a new page. class AnotherPage(SimplePage): pass Now you can register a new page. Note taht we do not need to define the template because it is already defined for SimplePage. page for=IMyObject name=SubjectTwo.html class=.MySkin.AnotherPage permission=... / You can now register your viewlets on that class (page) : viewlet name=anotherViewlet for=IMyObject view=.MySkin.AnotherPage manager=... class=... layer=your skin permission=... / Also note that all viewlets registered for SimplePage are also visible in the new page. You register globally visible viewlets on your SimplePage. Its simple and powerful, isn't it ? The most important thing you must see is the ability to register a viewlet on the context, the view, the manager and the request. This gives you a lot of control over the viewlet. Here is the code I'm using for my viewletmanager to have more control over the visibility of viewlets. I use this manager im my main template. class ContentViewletManager(WeightOrderedViewletManager): interface.implements(IContentViewletManager) def filter(self, viewlets): viewlets = super(ContentViewletManager, self).filter(viewlets) return [(name, viewlet) for name, viewlet in viewlets if getattr(viewlet, 'available', True)] If the viewlet provides the property 'available' it can control if it is visible or not. Among other things I use this often to have a dependency on user login. IUnauthenticatedPrincipal.providedBy(self.request.principal) Thanks again, Alec Munro On 10/10/06, Alec Munro [EMAIL PROTECTED] wrote: You were correct, because my skin was inheriting from z3c.layer.minimal.IMinimalBrowserLayer, which as best I can tell, doesn't inherit from the default layer (there's probably a ZCML directive to set this somewhere though), my pages/templates/viewlets/etc weren't available to be looked up. I made my skin inherit from IDefaultBrowserLayer, and everything's peachy. Thanks everyone, for all your help so far. Alec On 10/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think the layer attribute may be missing. browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public layer=.interfaces.MySkin / browser:template template=myskin_master.pt for=.interfaces.ISimplePage layer=.interfaces.MySkin / Kevin Smith - Original Message From: Alec Munro [EMAIL
[Zope3-Users] Recursion using viewlets.
Hi List, After a very thorough schooling in the use of viewlets in my other thread, I thought it might be better to start a new one for this topic. What's the recommended practice for dealing with recursion using viewlets? In my case, I have a hierarchy of objects, each implementing IContainSomething, and I want to display the entire hierarchy. I'm sure this is a simple case, and there's probably even good example code freely available somewhere, but I haven't yet found it. Thanks again! Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Intended scope of viewlets?
You were correct, because my skin was inheriting from z3c.layer.minimal.IMinimalBrowserLayer, which as best I can tell, doesn't inherit from the default layer (there's probably a ZCML directive to set this somewhere though), my pages/templates/viewlets/etc weren't available to be looked up. I made my skin inherit from IDefaultBrowserLayer, and everything's peachy. Thanks everyone, for all your help so far. Alec On 10/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think the layer attribute may be missing. browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public layer=.interfaces.MySkin / browser:template template=myskin_master.pt for=.interfaces.ISimplePage layer=.interfaces.MySkin / Kevin Smith - Original Message From: Alec Munro [EMAIL PROTECTED] To: Jürgen Kartnaller [EMAIL PROTECTED] Cc: zope3-users@zope.org Sent: Friday, October 6, 2006 11:39:23 AM Subject: Re: [Zope3-Users] Re: Intended scope of viewlets? I think I must be missing something about the way skins work now. I've created a master page that I can load when I don't specify a skin, but when I do specify a skin (++skin++MySkin), it is unable to find the page (404). Here's a rough approximation of my ZCML: interface interface=.interfaces.MySkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public / browser:template template=myskin_master.pt for=.interfaces.ISimplePage / There's lots more, and if any of it would be relevant, let me know, but this seems like it's the crucial part. I know it is finding the skin itself successfully, because the error message is not the standard Rotterdam one. The skin I'm using is currently just inherits from z3c.layer.minimal. I'll keep on trying things, but it's all kind of a shot in the dark right now. Thanks, Alec On 10/6/06, Alec Munro [EMAIL PROTECTED] wrote: Hi Jürgen, So, just to give a concrete example for my case, I might replace this (Metal-based): body div id=Navigation div metal:define-slot=navigation Nav tree needs a wee bit of work. /div /div div id=Content div metal:define-slot=body Some Content /div /div /body with this (viewlet-based): body div id=Navigation span tal:replace=structure provider:my.project.navigation Nav tree needs a wee bit of work. /span /div div id=Content span tal:replace=structure provider:my.project.content Some Content /span /div /body With seperate viewlet managers for navigation and content, or any other types of views I would expect to have on this page? Would a header viewlet manager also be sensible, say if I wanted a title that changed format depending on what type of content was being viewed? Finally, are there any best practices for packaging in viewlet-based templating? I'm currently creating this in my.project.browser.skin. How about the viewlet manager names, should they be my.project.*, my.project.browser.*, or something different? Probably some of these questions aren't relevant to the work you are doing on viewlets, but I find it helpful to try to follow industry practices as closely as possible, especially on something I don't have much experience with, so I am easily able to follow tutorials, and people who are helping me can more easily understand what I am trying to do. Thanks very much for your help so far, I am excited about implementing viewlets in our upcoming project. Alec On 10/5/06, Jürgen Kartnaller [EMAIL PROTECTED] wrote: Hi Alec. Alec Munro wrote: Hi List, I'm just getting up to speed with viewlets, having read a thread here and there in the past about them. I've installed the examples provided on this list, and while I believe I understand how they work, I don't understand in what circumstances they are most useful. The viewlets in the examples are all very small, such as retrieving an formatting a single piece of information about an object. However, from some of the posts to this list, I get the impression they are also being used for more complex items, like navigation menus. Menus are a perfect example for the use of viewlets. Have a look at z3c.menu. This package contains a base implementation for menus based on viewlets. Is there a recommended scope? Can they be described in a way such as develop your templates up to point X, then use a viewlet for development of further depth?. In my case, I am developing a new skin for a project, and my experience with metal says to make the entire HTML page a macro with slots for content and navigation. Is there a comparable viewlet-based paradigm? Yes there is one, see below Also, am I correct in stating that when working with viewlets, the only complete
Re: [Zope3-Users] Re: Intended scope of viewlets?
One more thing. When using this masterpage idea, what is the pattern for creating new pages? For example, I would traditionally have: MyObject/SubjectOne.html MyObject/SubjectTwo.html MyObject/SubjectThree.html Registered with: page for=IMyObject name=SubjectOne.html template=subjectone.pt / ... Where subjectone.pt would probably start with something like the following: html metal:use-macro=views/standard_macros/view Obviously, the above no longer applies, so what's the equivalent? My initial thought, if I am sticking as close to the above paradigm as possible, would be to have registrations for each that all reference the same class, being the one that implements the interface my masterpage is registered for. Something like the following: page for=IMyObject name=SubjectOne.html class=.MySkin.SimplePage / page for=IMyObject name=SubjectTwo.html class=.MySkin.SimplePage / ... In some ways, this makes sense to me, but it leaves me unsure how to properly differentiate the content on each page, without implementing something on each ViewletManager that detects the name of the page requested, and returns the appropriate content. Unless of course I can register Viewlets or ViewletManagers to specific page names? My guess is that the above pattern simply isn't applicable to the use of viewlets, and there is something else I should be using. I will investigate uses of viewlets, but if anyone knows the answer offhand, I would very much appreciate it. Thanks again, Alec Munro On 10/10/06, Alec Munro [EMAIL PROTECTED] wrote: You were correct, because my skin was inheriting from z3c.layer.minimal.IMinimalBrowserLayer, which as best I can tell, doesn't inherit from the default layer (there's probably a ZCML directive to set this somewhere though), my pages/templates/viewlets/etc weren't available to be looked up. I made my skin inherit from IDefaultBrowserLayer, and everything's peachy. Thanks everyone, for all your help so far. Alec On 10/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think the layer attribute may be missing. browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public layer=.interfaces.MySkin / browser:template template=myskin_master.pt for=.interfaces.ISimplePage layer=.interfaces.MySkin / Kevin Smith - Original Message From: Alec Munro [EMAIL PROTECTED] To: Jürgen Kartnaller [EMAIL PROTECTED] Cc: zope3-users@zope.org Sent: Friday, October 6, 2006 11:39:23 AM Subject: Re: [Zope3-Users] Re: Intended scope of viewlets? I think I must be missing something about the way skins work now. I've created a master page that I can load when I don't specify a skin, but when I do specify a skin (++skin++MySkin), it is unable to find the page (404). Here's a rough approximation of my ZCML: interface interface=.interfaces.MySkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public / browser:template template=myskin_master.pt for=.interfaces.ISimplePage / There's lots more, and if any of it would be relevant, let me know, but this seems like it's the crucial part. I know it is finding the skin itself successfully, because the error message is not the standard Rotterdam one. The skin I'm using is currently just inherits from z3c.layer.minimal. I'll keep on trying things, but it's all kind of a shot in the dark right now. Thanks, Alec On 10/6/06, Alec Munro [EMAIL PROTECTED] wrote: Hi Jürgen, So, just to give a concrete example for my case, I might replace this (Metal-based): body div id=Navigation div metal:define-slot=navigation Nav tree needs a wee bit of work. /div /div div id=Content div metal:define-slot=body Some Content /div /div /body with this (viewlet-based): body div id=Navigation span tal:replace=structure provider:my.project.navigation Nav tree needs a wee bit of work. /span /div div id=Content span tal:replace=structure provider:my.project.content Some Content /span /div /body With seperate viewlet managers for navigation and content, or any other types of views I would expect to have on this page? Would a header viewlet manager also be sensible, say if I wanted a title that changed format depending on what type of content was being viewed? Finally, are there any best practices for packaging in viewlet-based templating? I'm currently creating this in my.project.browser.skin. How about the viewlet manager names, should they be my.project.*, my.project.browser.*, or something different? Probably some of these questions aren't relevant to the work you are doing on viewlets, but I find it helpful to try
Re: [Zope3-Users] Re: Intended scope of viewlets?
Hi Jürgen, So, just to give a concrete example for my case, I might replace this (Metal-based): body div id=Navigation div metal:define-slot=navigation Nav tree needs a wee bit of work. /div /div div id=Content div metal:define-slot=body Some Content /div /div /body with this (viewlet-based): body div id=Navigation span tal:replace=structure provider:my.project.navigation Nav tree needs a wee bit of work. /span /div div id=Content span tal:replace=structure provider:my.project.content Some Content /span /div /body With seperate viewlet managers for navigation and content, or any other types of views I would expect to have on this page? Would a header viewlet manager also be sensible, say if I wanted a title that changed format depending on what type of content was being viewed? Finally, are there any best practices for packaging in viewlet-based templating? I'm currently creating this in my.project.browser.skin. How about the viewlet manager names, should they be my.project.*, my.project.browser.*, or something different? Probably some of these questions aren't relevant to the work you are doing on viewlets, but I find it helpful to try to follow industry practices as closely as possible, especially on something I don't have much experience with, so I am easily able to follow tutorials, and people who are helping me can more easily understand what I am trying to do. Thanks very much for your help so far, I am excited about implementing viewlets in our upcoming project. Alec On 10/5/06, Jürgen Kartnaller [EMAIL PROTECTED] wrote: Hi Alec. Alec Munro wrote: Hi List, I'm just getting up to speed with viewlets, having read a thread here and there in the past about them. I've installed the examples provided on this list, and while I believe I understand how they work, I don't understand in what circumstances they are most useful. The viewlets in the examples are all very small, such as retrieving an formatting a single piece of information about an object. However, from some of the posts to this list, I get the impression they are also being used for more complex items, like navigation menus. Menus are a perfect example for the use of viewlets. Have a look at z3c.menu. This package contains a base implementation for menus based on viewlets. Is there a recommended scope? Can they be described in a way such as develop your templates up to point X, then use a viewlet for development of further depth?. In my case, I am developing a new skin for a project, and my experience with metal says to make the entire HTML page a macro with slots for content and navigation. Is there a comparable viewlet-based paradigm? Yes there is one, see below Also, am I correct in stating that when working with viewlets, the only complete HTML page will be the primary skin file, with all viewlets based on snippets of HTML? Thats exacly what we at Lovely Systems do and it works perfectly :) We have one base template which is used for all pages. Instead of defining slots to be filled by other templates it contains viewlet managers. We then provide different view classes to be able to register our viewlets for the pages of the application. The view classes are empty classes they are just providing the class name or if they provide additional functionality they also provide an interface. It is then possible to register the viewlets for specific pages. The most important thing on viewlets is that they are adapters on the *context*, the *request*, the *view* and the *manager*. The viewlet solution is an extremely productive way to implement a complex application. Make sure you read this : http://blogs.lovelysystems.com/srichter/2006/09/20/the-skin-browser-and-lovely-systems-new-development-workflow/ Stephan Richter describes here our use of the viewlet concept and our development workflow. The most important part was the development of the package z3c.viewtemplate. This package makes it possible to separate the development of the HTML page from the implementation of the python view class. The package is not yet perfect but gives us what we need right now but it needs a better integration into forms and viewlets. Expect more in the near future! In our applications really everything is done using viewlets, there is no single use of fill-slot in the hole application! My questions are fairly broad-ranging, I know, but I have thus far been unable to find a straightforward explanation of viewlets, in terms of how they relate to general site development. All I can tell you now is : USE VIEWLETS, USE VIEWLETS, USE VIEWLETS, Jürgen ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Intended scope of viewlets?
I think I must be missing something about the way skins work now. I've created a master page that I can load when I don't specify a skin, but when I do specify a skin (++skin++MySkin), it is unable to find the page (404). Here's a rough approximation of my ZCML: interface interface=.interfaces.MySkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:page name=my.project.index.html for=* class=.myskin.SimplePage permission=zope.Public / browser:template template=myskin_master.pt for=.interfaces.ISimplePage / There's lots more, and if any of it would be relevant, let me know, but this seems like it's the crucial part. I know it is finding the skin itself successfully, because the error message is not the standard Rotterdam one. The skin I'm using is currently just inherits from z3c.layer.minimal. I'll keep on trying things, but it's all kind of a shot in the dark right now. Thanks, Alec On 10/6/06, Alec Munro [EMAIL PROTECTED] wrote: Hi Jürgen, So, just to give a concrete example for my case, I might replace this (Metal-based): body div id=Navigation div metal:define-slot=navigation Nav tree needs a wee bit of work. /div /div div id=Content div metal:define-slot=body Some Content /div /div /body with this (viewlet-based): body div id=Navigation span tal:replace=structure provider:my.project.navigation Nav tree needs a wee bit of work. /span /div div id=Content span tal:replace=structure provider:my.project.content Some Content /span /div /body With seperate viewlet managers for navigation and content, or any other types of views I would expect to have on this page? Would a header viewlet manager also be sensible, say if I wanted a title that changed format depending on what type of content was being viewed? Finally, are there any best practices for packaging in viewlet-based templating? I'm currently creating this in my.project.browser.skin. How about the viewlet manager names, should they be my.project.*, my.project.browser.*, or something different? Probably some of these questions aren't relevant to the work you are doing on viewlets, but I find it helpful to try to follow industry practices as closely as possible, especially on something I don't have much experience with, so I am easily able to follow tutorials, and people who are helping me can more easily understand what I am trying to do. Thanks very much for your help so far, I am excited about implementing viewlets in our upcoming project. Alec On 10/5/06, Jürgen Kartnaller [EMAIL PROTECTED] wrote: Hi Alec. Alec Munro wrote: Hi List, I'm just getting up to speed with viewlets, having read a thread here and there in the past about them. I've installed the examples provided on this list, and while I believe I understand how they work, I don't understand in what circumstances they are most useful. The viewlets in the examples are all very small, such as retrieving an formatting a single piece of information about an object. However, from some of the posts to this list, I get the impression they are also being used for more complex items, like navigation menus. Menus are a perfect example for the use of viewlets. Have a look at z3c.menu. This package contains a base implementation for menus based on viewlets. Is there a recommended scope? Can they be described in a way such as develop your templates up to point X, then use a viewlet for development of further depth?. In my case, I am developing a new skin for a project, and my experience with metal says to make the entire HTML page a macro with slots for content and navigation. Is there a comparable viewlet-based paradigm? Yes there is one, see below Also, am I correct in stating that when working with viewlets, the only complete HTML page will be the primary skin file, with all viewlets based on snippets of HTML? Thats exacly what we at Lovely Systems do and it works perfectly :) We have one base template which is used for all pages. Instead of defining slots to be filled by other templates it contains viewlet managers. We then provide different view classes to be able to register our viewlets for the pages of the application. The view classes are empty classes they are just providing the class name or if they provide additional functionality they also provide an interface. It is then possible to register the viewlets for specific pages. The most important thing on viewlets is that they are adapters on the *context*, the *request*, the *view* and the *manager*. The viewlet solution is an extremely productive way to implement a complex application. Make sure you read this : http://blogs.lovelysystems.com/srichter/2006/09/20/the-skin-browser-and-lovely-systems-new-development-workflow/ Stephan Richter describes here our use of the viewlet concept and our development workflow. The most important part
[Zope3-Users] Intended scope of viewlets?
Hi List, I'm just getting up to speed with viewlets, having read a thread here and there in the past about them. I've installed the examples provided on this list, and while I believe I understand how they work, I don't understand in what circumstances they are most useful. The viewlets in the examples are all very small, such as retrieving an formatting a single piece of information about an object. However, from some of the posts to this list, I get the impression they are also being used for more complex items, like navigation menus. Is there a recommended scope? Can they be described in a way such as develop your templates up to point X, then use a viewlet for development of further depth?. In my case, I am developing a new skin for a project, and my experience with metal says to make the entire HTML page a macro with slots for content and navigation. Is there a comparable viewlet-based paradigm? Also, am I correct in stating that when working with viewlets, the only complete HTML page will be the primary skin file, with all viewlets based on snippets of HTML? My questions are fairly broad-ranging, I know, but I have thus far been unable to find a straightforward explanation of viewlets, in terms of how they relate to general site development. Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Simple Sources tutorial?
On 9/7/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Fred Drake wrote: On 9/6/06, Stephan Richter [EMAIL PROTECTED] wrote: I still use vocabularies. I still don't get sources. Vocabularies have not been deprecated yet. I think sources have to become much more developer-friendly before finding wide-spread support. Odd that you should mention this. ;-) We have a component that should make many of the common cases *much* easier to work with for sources. I expect it will be ZPLed, but don't know when. I think I got sources, but I agree with Stephan: They're hard to work with in the common case. It would be great if they became easier. I'm looking forward to the open-sourcing of that component! Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users Interesting. I'll probably revert to vocabularies, but keep a close eye on Fred's component. I never particularly had a problem with vocabularies, but I did think there were probably ways to streamline their use, and I kind of assumed that's what sources would do. Thanks! Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Simple Sources tutorial?
Anyone have a simple reference on the usage of sources? I'm in need of a vocabulary-like thing, and my understanding is that vocabularies have been replaced by sources, but I am unable to find any documentation on their use. There are numerous discussions on specific details of sources, but I haven't found any real tutorials that cover how you register them, how you reference them, and real-world examples of their use. Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Uploading and extracting a zip file.
Hi List, This seems like it should be relatively easy to solve, but I haven't been able to find a solution so far. I want to upload a zip file to a certain component, and have the component automatically extract and process the contents of the zip file. In this case, I'm uploading an odt file, and I want to extract the content.xml and process it. The tricky part is actually accessing the zip file. I get the raw data all right, but ZipFile requires a file-like object or path. I tried using StringIO to wrap the data, and passing that to ZipFile, but then I get BadZipfile: File is not a zip file. Thanks for any help. Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Uploading and extracting a zip file.
Hi again, As it turns out, the data is available as a FileUpload object, which I can use just like a file, and that works quite well. Thanks for reading, Alec On 5/10/06, Alec Munro [EMAIL PROTECTED] wrote: Hi List, This seems like it should be relatively easy to solve, but I haven't been able to find a solution so far. I want to upload a zip file to a certain component, and have the component automatically extract and process the contents of the zip file. In this case, I'm uploading an odt file, and I want to extract the content.xml and process it. The tricky part is actually accessing the zip file. I get the raw data all right, but ZipFile requires a file-like object or path. I tried using StringIO to wrap the data, and passing that to ZipFile, but then I get BadZipfile: File is not a zip file. Thanks for any help. Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Please Guido, pick me, pick me!
On 2/3/06, Tonico Strasser [EMAIL PROTECTED] wrote: Alen Stanisic wrote: On Fri, 2006-02-03 at 11:54 +0100, Lennart Regebro wrote: On the name change idea, I think it's just gonna make things more confused. What, there is now Zope 2, Zope 3 AND Zope Zingo? I think the idea was Zope 3.2 Zingo, Zope 3.4 Bingo, not Zope Zingo :) This way it would be clear it is Zope 3. I guess something like Ubuntu 5.10 Breezy. Hehe, I'm +1 for funny code names and -1 for renaming. Tonico This has been an interesting thread. My feeling is that the Ubuntu style code names are a very good idea. I know the fixed-length release cycles are still fairly new, but making them a bit sexier seems like a good idea in this case. Ideally, it would go along with a new website, or perhaps some wiki pages, with a roadmap. Among geeks, new releases are exciting business. Of course, the people actually making the releases are already so busy, I have no idea who would maintain and update such a roadmap. But, on the other hand, I'm just fine with Zope's current level of advocacy. Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Looking up the schema of an adapter?
Hi List, I'm building an e-commerce system, and within it, I have Deliverable objects, and ProductOrder objects. A ProductOrder is currently treated as an adapter to a Deliverable, it represents an order for that Deliverable. There are a number of different Deliverable types, most with corresponding ProductOrder types (I use ZCML to register each ProductOrder as an adapter to each Deliverable type). The ProductOrder types have common properties, such as quantity of items ordered, and unique properties, such as color, or language. What I want to be able to do is lookup the schema of a ProductOrder from the context of the corresponding Deliverable, for the purpose of creating an add form for that ProductOrder. Currently, I can accomplish this by actually instantiating a ProductOrder as an adapter to the Deliverable, and then looking at __implemented__.declared, but then the ProductOrder get discarded, and reinstantiated when the Add Form is submitted. I would like a straightforward way to lookup the schema and create the Add Form without having to instantiate the ProductOrder. Alternatively, if anyone can suggest any modifications to my overall system that will allow me the same functionality, that would be great. Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Permission required for renaming?
Hi Stephan, Actually, my users don't have that role(permission?), because I got the impression that having it would give them access to a number of things I don't want them to see, such as the metadata and introspector tabs. Is that strictly required for any kind of renaming/copying/pasting? Is there an easy way to change that? Thanks for your response, Alec On 1/4/06, Stephan Richter [EMAIL PROTECTED] wrote: On Wednesday 14 December 2005 12:40, Alec Munro wrote: Any ideas where I can go with this? It seems like there's probably a simple step I'm missing in the creation of my components, but so far I've had no luck figuring it out. Are you sure your user has the zope.ManageContent role? (BTW, please always post responses to the list as well.) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Large project organization?
Hi List, I'm trying to ensure the most efficient organization of my projects, and I'm wondering what the best practices are. I try to divide things up into modules when it seems appropriate, but where should those modules be located? What's the logic for deciding if a module should be inside another module, vs. on it's own? So far, I haven't had any problems with anything I've tried, but I do prefer to plan ahead as much as possible. Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Permission required for renaming?
Thanks for the response. They are local users, and it's specific to every container type that I've created, I haven't had the chance to test with regular folders. The containers that I have inherit from OrderedContainer or BTreeContainer, and tend to be fairly minor customizations, simply adding a couple properties or methods. Hope that helps. I can do a little more testing tomorrow if you have any leads. Thanks again, Alec On 12/13/05, Stephan Richter [EMAIL PROTECTED] wrote: On Wednesday 30 November 2005 16:16, Alec Munro wrote: My users are unable to rename things, seemingly everywhere. They can add, remove, but not rename, or cut/copy. I'm not sure how to set the permission for this. I think we need some more specific background information to help you out here. For example: Are those local or global users? Is this a specific container, or is it also true for a folder? ... Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] logout feature with zope3
Hi Jane, I'm not an expert, but having run into a similar situation myself, you may be out of luck. The HTTP Auth (what generates the popup window) is almost entirely separate from other browser functionality, and once the authentication is complete, I don't know of any way you could access the password. It's possible that you could create a custom authentication method that combined Basic HTTP with cookie based Authentication, but it might be simpler to setup a login form for your users, if that's an option, and use the standard cookie based auth. Actually, a third option might be to use the Basic HTTP auth, and then use request.principal to lookup the actual principal information, including login and password. I believe Zope is currently storing passwords plain text, so this might work for your purposes. This seems rather unclean to me, but it might get the job done. As I said, I am not an expert, but I hope this is at least somewhat helpful. Alec Munro On 12/6/05, Jing Song [EMAIL PROTECTED] wrote: Hi, I have problems to implement my zope logout feature. Since the Basic HTTP Authentication does not funcition properly, I'm trying to work around by using Philipp's cookie based authentication solution showing in the Worldcookery example. But if I only use the default pop-up login window without using a customized login form, how could I get the user name and the password to set the cookie so that the logout can also function. Any idea or example would be very much appreciated. Thank you in advance! Jane Yahoo! Personals Let fate take it's course directly to your email. See who's waiting for you Yahoo! Personals ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Permission required for renaming?
As far as I can tell they do, the objects containers primary interface inherits from IContainer, and they have set_schema on that interface. Additionally, they can add new containers, and their contents, but still be unable to rename the contents. Thanks, Alec On 12/1/05, Chris Withers [EMAIL PROTECTED] wrote: Alec Munro wrote: My users are unable to rename things, seemingly everywhere. They can add, remove, but not rename, or cut/copy. I'm not sure how to set the permission for this. Do they have the necessary permissions on the objects container rather than the object itself? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Permission required for renaming?
Hi List, My users are unable to rename things, seemingly everywhere. They can add, remove, but not rename, or cut/copy. I'm not sure how to set the permission for this. Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Recommended policy for extension of the built-in skins and macros?
Hi All, I've managed to dip my toes rather deeply in Zope3 without ever approaching the skins/layers aspect of it. I'm finally in a position to do that, and most of the examples I find extend the Rotterdam skin, and simply override it's macros. Is this simply for convenience, as there is a lot of useful functionality provided by these macros? Or is there some grander reason for using the existing with simple customizations? The main thing I could think of was that by doing this, you will can generally ensure consistent macro naming across different sites, which I suppose is helpful. I'm a very minimalist guy as far as HTML goes, so my initial inclination is generally to start with with the simplest thing possible, and expand it when necessary. What are people's experiences with this (keeping in mind that I am likely misunderstanding some large part of the way skins and layers are supposed to work :) ? Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Disappearing dictionary. Upon restart, dictionary resets.
Woohoo!
This is precisely the advice I needed.
I think where I got tripped up is that I rarely use class attributes
outside of Zope (setting everything up in __init__), so I actually
stopped treating them as class attributes, and pretended they were
simply part of the initilization.
I think I'm going to examine all my code this morning, see if I'm
sinning in this fashion anywhere else.
Thanks Chris, and everyone else who replied.
Alec
On 9/26/05, Chris Withers [EMAIL PROTECTED] wrote:
Alec Munro wrote:
class SomeObj:
some_dictionary = PersistentDict({})
ouch, never use mutables for class attributes, for exactly the reasons
you've found.
two points:
1. the dict will get newly created every time this code runs, ie: each
time Zope starts.
2. the object is never seated into the ZODB. It's an attribute of the
class, not any instance of the class, and it's only instances of the
class that are persisted by zodb.
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Disappearing dictionary. Upon restart, dictionary resets.
Well, I narrowed it down a little bit more.
I've been initializing the dictionary in the class declaration, like
the following:
class SomeObj:
some_dictionary = PersistentDict({})
Now, for some reason, each time Zope was started, it called this, and
whenever I tried to access the some_dictionary propery on any of my
objects, it returned the newly created one. Is this what should be
happening?
Alec
On 9/26/05, Alec Munro [EMAIL PROTECTED] wrote:
I've tried it with PersistentDicts and PersistentMappings, and no luck.
It's very odd, I think there must be some fundamental step towards the
use of a mapping in Zope that I'm missing.
Alec
On 9/21/05, Lennart Regebro [EMAIL PROTECTED] wrote:
On 9/20/05, Alec Munro [EMAIL PROTECTED] wrote:
I have a content component that has a property that is a dictionary,
the keys of which are objects (content components themselves). The
values are lists of strings. I've tried implementing this a couple
different ways, but each time I restart, the dictionary comes up
empty.
You need to use a PersistentDictionary. Ordinary dictionaries do not
detect that they have changed, and so do not get written to the ZODB.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Confusion about PAU usage.
Hi Garrett, Thanks for the response. So far, I have subclassed InternalPrinciple, because I was looking to create a container based principal source, and PrincipalFolder seemed like the obvious choice to subclass at the time. Because PrincipalFolder contains InternalPrincipals, I subclassed InternalPrincipal to create my principal classes (I have three, each representing different types of users). I'm sure that this was the wrong way to do things, but it gave me quick satisfaction, by allowing me to use the ZMI add menu to add each of my three types of principals and Authenticate against them. So having three types of users was one of my requirements. The differences between these users are relatively small, but having them in separate classes seems to allow me quite a lot of control. Another requirement,as mentioned, each of these principles has properties, which would ideally be editable by a manager at any time(at least during development), or the users themselves, once logged in. What is the preferred way to do this? I'm not entirely attached to subclassing to differentiate my principles, but it does allow me to use Principal Annotations in a way that is very clear to me. Thanks for your help, Alec On 8/26/05, Garrett Smith [EMAIL PROTECTED] wrote: The PAU mechanisms involving InternalPrincipal and PrincipalInfo are internal to its workings. From what I can see, these shouldn't impact what you're doing. If you want the grimy details, look at the README.txt doctest file in zope/app/authentication. However, these mainly apply to plugin developers. To store additional information for a principal, use the principal annotation utility. E.g. were you in a browser view: util = zapi.getUtility(IPrincipalAnnotationUtility) annotations = util.getAnnotations(self.request.principal) I would strongly discourage you from subclassing InternalPrincipal -- it's, well, internal :-) If annotations aren't working for you, give me the specifics and I'll see if I can help. -- Garrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alec Munro Sent: Tuesday, August 23, 2005 10:06 AM To: [EMAIL PROTECTED] Cc: zope3-users@zope.org Subject: Re: [Zope3-Users] Confusion about PAU usage. On 8/22/05, Christoph Frick [EMAIL PROTECTED] wrote: On Mon, Aug 22, 2005 at 11:47:40AM -0300, Alec Munro wrote: In my situation, I am trying to create principals with additional properties, and initially I did that by extending InternalPrincipal. That worked fine, until I realised that when I authenticated, I was getting back a PrincipalInfo instance, which does not contain the additional properties. Additionally, I wish to have multiple types of users, so I had extended InternalPrincipal a couple of times, to create a few different classes, the distinction of which is obviousy lost when authenticating ATM. i guess what you really want here are annotations of principals. have a look in the zope3 book you can download from zc's site. there is AFAIR a section adressing this problem with lots of examples and i think the section also sheds some light on the whole principal and annotation in general. -- cu I've given this a try, and right now I am having a problem figuring out what I am supposed to attach the annotation information to. My specific principals are extensions of IInternalPrincipal, which doesn't have an ID, and as such, doesn't work for principalannotations as I have experienced them so far. This is one of the reasons why I would like a guide on the differences between InternalPrincipals, PrincipalInfo's, and Principal's. The standard Principal Folder contains InterrnalPrincipals, so I assumed that was the type I should be extending. I imagine that if I were to log in as one of these principals, I might then have access to the annotations. However, at least for testing purposes, I would prefer to have access to them when doing site management. Anyone have any advice on how to proceed with this? Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Everything printing as ASCII?
I think it was using StringIO. My default python encoding was ASCII, so I changed that, and it ended up solving my problems, so I haven't looked further into this, but I assume that while all of the pieces were unicode to start with, Python was converting some of them to ASCII earlier on. I believe I'm getting the hang of this encoding thing, but don't quote me on that. Alec On 8/10/05, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 09 August 2005 14:17, Alec Munro wrote: I've been having some unicode troubles, so I put a print statement in the StringIO class, and it seems that everything is type 'str', rather than unicode. Is this how it is supposed to be? cStringIO only supports str, not unicode. Use StringIO instead. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Allowing an other value in choice fields sourced from vocabularies.
Hi List, We want to allow a choice field with an other option, that allows them to type in an arbitrary value. So far, we have this working up until the point of validation. At the point of validation, it notices that the other value is not in the vocabulary, and raises ConstraintNotSatisfied. My initial thought is to create a new field type for SuggestedChoice, that simply doesn't perform the checking against the vocabulary values. Has anyone else run up against this? Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Multi-directional adapters.
I'm sure I'm using the wrong terminology, so here's what I'm trying to do. I have a generic container type (someContainer), and a specific object type (objA). objA can only be contained within AContainer (or containers that implement IAContainer), so in order to add objA to someContainer, we would need an adapter between IAContainer and IsomeContainer. To complicate the mix, there is no such adapter (because I don't want objA stored in someContainer). However, there is an adapter between IBContainer, and IsomeContainer. There is also an adapter between IobjA and IobjB. Multi-directional adapter seems appropriate, because in order for things to work, both the container and the object to be contained. Is this common practice, or even possible? It seems like it would probably work, but I still have much to learn, so please advise. Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Providing schema information to Flash
Hi List, We're building a fairly sophisticated application that uses Flash as it's primary front end. I would really like to keep the specific data logic in Flash as simple as possible. I have a good communication setup using JSON-RPC (thanks to Jim Washington!), and now I want to expand on it, and figure out a good way to provide Flash with information about what types of data it should expect. I'm not sure how to accomplish this. My initial idea was to provide information about the interfaces to Flash, and allow Flash to interpret those. Any advice on the best way to proceed would be very helpful. Thanks, Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Self-updating components?
Hi List, I'm finally getting into the swing of Zope 3 development, and I've been doing a bit of thinking on how to integrate everything with Subversion. The general process I've settled on is as follows (this is all happening on a development server): 1.SVN Update Code locally 2.Edit Code 3.Test Code on local Zope 4.SVN Check-in Code from local 5.SVN Check-out/Update code on development server 6.Test Code on development Zope 1.If successful, restart development Zope. 2.If unsuccessful? The problem I have is how to automate steps 5 and on. I could put hooks into Subversion, but without some tricks, it seems like it would result in a lot of processing and restarts on the development server. Another idea I had, and the one that intrigues me the most at the moment, is making each component capable of updating itself. I really have no idea how it should work, if it's at all feasible, or advisable. Any hints or suggestions on this? ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Recommend way to ..(question inside)
Sorry for the vague subject, but I wasn't sure how to summarize this. It's not exactly a Zope question, but perhaps Zope has some tricks to make it easier. In a couple of situations, I want to have a collection of objects, and allow users to select from those objects, and personalize them. The way I was thinking about this was that I would have a second class of objects that contained the additional properties as well as a property containing the personalized object. This seems to be similar to the way adapters operate. However, generally an adapter is created when used, and discarded, correct? What is the recommended way to go about this? Hopefully that is enough information, and someone can confirm my speculations. Thanks, Alec Munro ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Zope 3.1.0 Zope3 Developer's Book
On 6/18/05, Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 18 June 2005 15:19, Corey wrote: Question: with all these new changes since 3.0 ( which all look very good! ), approximately how much of the Zope3 Dev Book becomes misleading/incorrect/obsolete? Primarily I'm wondering whether it is still possible to use the Zope3 dev book , follow along with it's examples/excersises without constantly running into troubles? Yeah, I think that most of it will still work just fine. I think someone reported that step 7 or 8 of the messageboard product was still working on the trunk, which is impressive. Before the final release I will take some time and make sure that all the packages will still work without modification. Right off the bat, I can see that the stuff on Services will be a point of hassle and confusion for many people starting off w/ Zope 3.1 and the current Zope3 dev guide. Right, this cannot be avoided. But I already talk very little about services in the book. Are there prospective plans to keep the book updated with the releases, or are there simply not enough resources/time available at this point to do so? I am not sure how much time I will have. I am very booked till school starts again. I would need at least a week to get everything updated, not to mention covering new features. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users I would be very interested in attempting to provide an update to the book, to cover new features in 3.1. I still have a lot to learn, but I thought that perhaps it would be helpful to pick a section in the book that has changed (for example, I believe Chapter 20, on workflow), and attempt to document the appropriate way to handle it in 3.1. As I said, I do have a lot to learn, but as long as someone points me in the right direction, I would feel comfortable attempting this. Is this something that would be helpful? Alec ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
