[Zope3-Users] Accessing an attribute of 'context'
Hi, How can I access an attribute of a BrowserView's context if the attribute's name is not hardcoded? Example: Works: self.context.myattribute Works: removeSecurityProxy(self.context).__getattribute__('myattribute') What I want to do: Doesn't work: self.context.__getattribute__('myattribute') Regards, Frank ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Accessing an attribute of 'context'
On 2/20/06, Frank Burkhardt <[EMAIL PROTECTED]> wrote: > Works: self.context.myattribute > > Works: removeSecurityProxy(self.context).__getattribute__('myattribute') > > What I want to do: > > Doesn't work: self.context.__getattribute__('myattribute') getattr(self.context, 'myattribute') -- 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] Granting Roles - What am I missing?
On Sunday 19 February 2006 14:43, David Johnson wrote: > I tried, but I continue to get the same error. I guess the question is, why > doesn't granting the "zope.ManageContent" permission to my principal solve > this problem in either case? Is it a local principal? If so, make sure that all the objects in the traversal path have a __parent__ attribute. Otherwise the security cannot be looked up correctly. Almost certainly smells like a bug. 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
Re: [Zope3-Users] Accessing an attribute of 'context'
On Monday 20 February 2006 06:58, Frank Burkhardt wrote: > Doesn't work: self.context.__getattribute__('myattribute') That's because __getattribute__ has no security declaration. Anyways you should not use it this way anyways. Frank's response should do the trick. 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] Re: [Zope3-dev] 'standart viweletManger' for web-site
On Sunday 19 February 2006 16:11, Garanin Michael wrote: > Question: Where layer for web-site (not ZMI)? I offer create > 'z3site'-layer and define 'standart' viewler managers for web-site(not > ZMI) : IHead, ICSS, .., ILeft, IRight(!), etc. Hi Garanin, unfortunately you left out so many verbs that I cannot understand the question. I admit that the Boston skin is fairly formal. Simpler uses of viewlets and viewlet managers are at svn.zope.org/zope.webdev and the SchoolTool project. 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] Re: The Zope Software Certification Program and Common Repository Proposal
On Mon, 20 Feb 2006 21:28:09 -, Stephan Richter <[EMAIL PROTECTED]> wrote: I have spent the last two weeks working on a proposal that defines a Zope Software Certification Program (ZSCP) and a Common Repository that implements this process. The proposal is attached to this mail. I welcome any comments about it! Hi Stephan, I have only skimmed the document, since it's 1am and I'm going to the mountains tomorrow. I expect a triple-digit post count in this thread when I return. :) I think the proposal is very well put-together. I think it admirably tries to make the Zope 3 community more inclusive of more peripheral developers who simply use the framework, and I think this will benefit Zope immensely if done right. My immediate concern is about resources: Who will have the time or incentive to police the common repository and grant certification? It seems to be a non-trivial process that may end up being quite time-consuming. It may be perceived as too much red tape. It may be perceived as too much centralised control, especially around licensing. At times it may also be open to debate, and a means of resolving disputes would seem necessary. There are certainly a lot of tick-boxes in your table! :-) Secondly, and partly because I'm expecting this to come up in my absence: your proposal is eerily simlar to Alan's two-level Plone collective post to plone-dev, about having an "approved" list of contributors and packages in a fenced-off repository, in addition to the collective. One obvious parallel here, by the way, is with the svn.plone.org/plone repository. That one is controlled by the Plone Foundation, requires a contributor agreement, and imposes restrictions on license and quality (albeit not as formally as you do). I think this is possibly a more valid comparison than with the Collective. I'm actually +1 on your proposal in spirit (if it can be shown to work, and if there is a broad consensus in the community to support it - in fact, this is important: if there is too much division, the proposal would likely be self-defeating) and -1 on his. The reason is that the Plone world is quite different from the Zope 3 world (although there are hard-core Plone developers who sit in both). The Plone community is much larger but naturally also more dispersed. The software is much more narrowly defined (depending on your point of view I suppose, but I mean - it's a CMS, Zope 3 is a framework) and the components developed for it are much closer to the user. Plone thrives on the size and vibrancy of its community. A very large part of its success comes from third party products that people find and marry with Plone to solve their problems. Without the low bar to contributing such components, without an open and very democratic Collective, and without "meta-data" on http://plone.org/products, I don't think this would be possible, certainly not as successful. The uptake of third party product users and contributors, and I think maybe also the quality, has improved quite significantly since we introduced the Products section on plone.org. A framework like Zope 3, and framework-level third party components, thrives more on control and consistency in vision and implementation. (In part, you're solving that with better guidelines around how to write code, guidelines that Zope 3 adopters also benefit from.) I think that the lower down the stack you go, the higher the degree of centralised quality-control needs to be. This, however, is at the expense of perceived eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3. Put differently, I think that *some* Plone components ought to move lower down the stack, target re-usability in different systems, and thus be subject to somewhat different rules. Perhaps these components shouldn't have been Plone components in the first place, or perhaps their evolution would start in Plone and move down the stack. But I think it would be damaging for the Plone community, given its current shape and culture, to impose those rules across the types of components that are higher up the stack - arguably those components which should be "Plone" components still. I'd also note that we solve (or try/continue to solve) some of the visibility and evaluation problems on http://plone.org/products (which is of course open source, albeit GPL, and you can re-use any of this you see fit). Some of those same things, you solve with more technical means - automated testing, common file layouts, XML metadata files. Again, I think these approaches work better at the small-component-high-reusability/framework level than they do with the types of user-facing components that typically land in the Collective. Although you proposal is not technical in design, it's technical in implementation (so to speak). Perhaps it would be
RE: [Zope3-Users] The Zope Software Certification Program and CommonRepository Proposal
Hi there, Certification would go some way to separating mature projects from those in their infancy, but in my mind what the existing Plone/Zope product repositories lack most is a mechanism for user feedback. I would like to see: 1. Some kind of self-submission categorizing (or classification) as per the existing attempts at categorization 2. A peer vote based ranking system that can be used as a sort, with a nominal minimum number of votes before it can be ranked. 3. Another sort by 'popular' packages - ie by the number of votes above average 4. Certified 1-4 packages getting listed first 5. User comments I think this would go a long way to identify those little gems that otherwise only get picked up by accident or referral from the mailing lists because the author has no real interest in the process, and needs cajoling just to write up some adequate docs. Certification processes seem likely to reflect the existing use of a package rather than encourage new development or innovation. Cheers, Brett ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] browser:form
I’ve implemented the browser:form ZCML directive. The implementation works well until I add an __init__ method to my view class. The following error is generated. File “/home/myuser/Zope-3.2.0/build/lib.linux-i686-2.4/zope/app/form/browser/editview.py", line 76, in widgets return [getattr(self, name+'_widget') AttributeError: 'SimpleViewClass from edit.pt' object has no attribute 'name_widget' Here is the __init__ that leads to the error ---: class Function(object): """A transaction function.""" __used_for__ = ITPM def __init__(self, context, request, base_url=''): self.context = context self.request = request self.base_url = base_url def setData(self): """Bland setData implementation.""" --- -- David Johnson [EMAIL PROTECTED] 201 Main Street Suite 1320 Fort Worth, TX 76102 (877) 572-8324 x2200 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] LDAP Authentication
I have installed, configured, registered, named and activated ldapadapter with Public permission. Ditto for ldappas. Both are svn revision 41715. Both pass their tests. There are no errors when Zope 3.2.0 restarts. Everything looks fine, but Zope ignores LDAP and uses (or tries to use) Basic Authentication. There seems to be a step missing somewhere, but where? How do I get Zope 3 to authenticate with LDAP? We routinely use LDAPUserFolder in several Zope 2 instances but we're not even getting to the LDAP server with Zope 3. What am I missing, please. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: > +---[ Stephan Richter ]-- > | Hello everyone, > | > | With the development of Zope 3, the Zope developers committed to a new > | development process and higher software quality guidelines. With the > adoption > | of Zope 3 technologies in the wider Zope community, we should also start > | using the process for third party package development. > | > | I have spent the last two weeks working on a proposal that defines a Zope > | Software Certification Program (ZSCP) and a Common Repository that > implements > | this process. The proposal is attached to this mail. I welcome any comments > | about it! > > So in order to even get your Open Source package LISTED, you have to sign > over > the rights of your code to Zope Corp (currently, Zope Foundation later), and > then > check it into the svn respository. > > Is this is correct? No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. I think both the ZSCP and the common repository (in the context of the ZF) are a great idea. We should try to have as much stuff as possible in the common repository, but we shouldn't make the process dependent on it. I'm therefore still suggesting to divide up the proposal. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users