Re: [Zope-dev] Acquisition Confusion :S
Evan Simpson wrote: > Here are the two and a half rules for deriving acquisition from a dotted > expression: > > 1. A.B == (B o A), where A is an unwrapped object > > 2. (self o parent).B == > a. (self.B o (self o parent)), if B is found in 'self' > b. (parent.B o (self o parent)), if B is found in 'parent' Who decided these rules and why are they like they are? So, is the working below now correct? (I feel like I'm back in School doing maths ;-) > > A has attributes B and C, C has attribute D A.B.C.D = (B o A).C.D - rule 1 = (A.C o (B o A)).D - rule 2b = ((C o A) o (B o A)).D - rule 1 = ((C o A).D o ((C o A) o (B o A))) - rule 2a = ((C.D o (C o A)) o ((C o A) o (B o A))) - rule 2a = (((D o C) o (C o A)) o ((C o A) o (B o A))) - rule 1 Now, if you apply simplification one way (top to bottom?) you get: = ((D o C) o ((C o A) o (B o A))) - simplification ...which can't be simplified, AKAICS However, if you simplify bottom to top, you get: = (( D o (C o A)) o ((C o A) o (B o A))) - simplification = ( D o ((C o A) o (B o A))) - simplification ..which is what you got. Where is the order of simplification defined? Is there a 'correct way'? Does it make a difference? (the above example would seem to suggest not, other than in searchign efficiency) ...and of course, how does Zope do it? > In other words, aq_inner is the left-inner-most wrapper. Find the leftmost > 'o' in the expression, and you've got it. Thanks, that's _much_ cleaer than the slides :-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MethodGeddon
Shane Hathaway wrote: > > http://dev.zope.org/Wikis/DevSite/Proposals/DTMLExpressionSyntax > Hmm. No, that's not really related. How so? Can you list the differences and if they're orthogonal try and explain it to me? You 'get' this but I sadly don't :( (yet.. ;-) > > > http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterface > > Hurm, have I duplicated that with this? > > http://dev.zope.org/Wikis/DevSite/Proposals/GenericMethodInterface > Just make sure they both refer to each other for now. Done :-) > That's the plan. In fact, there is a difference between "templates" > and "methods", so the base class might be called "MethodOrTemplate". What is the difference between methods and templates other than the scripting paradigm used? Whether it's template or procedural scripting (or functional or declarative ;-) shoudln't the underlying method structure be the same? I think that's what you're sugesting, so maybe just call it 'CallableObject' rather than "MethodOrTemplate"? > It's not, really, but the current management interface is restrictive > on the number of tabs you should use. Yes, I've noticed that too.. Perhaps management tabs should have the option of a 'second row' of tab? So, for example, you click on security, then the next row of tabs appears just below the first lot (different colour maybe?), in the security example the second row would contain: -'Permissions' (the default), -'Local Roles' -'Proxy Roles' (in the case of CallableObjects) -'User Defined Roles' So, you wouldn't need the varying 'Proxy','Defined Permissions' and 'Security' tabs that currently exist (didn't notice that 'Security chanegs its name to 'Defined Permissions' on methods until now, how confusing :S) which I think would make the interface a lot clearer... What do you think? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > Who decided these rules and why are they like they are? They follow directly from the way the Acquisition machinery works, which was set up by Jim Fulton. > So, is the working below now correct? (I feel like I'm back in School > doing maths ;-) Yes. > Where is the order of simplification defined? In the Acquisition machinery, which simplifies upwards because that's the way it constructs the wrappers. Cheers, Evan @ digicool & 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] DataSkin propoerty Sheets/Providers.
I think I have a decent handle on this concept, but something seems lacking, I hope someone can clear it up :) So, let us say I have an object, call it a Member. :) And let us say I want to be able to add a property sheet to it in a customizer/specialist. AIUI, I should be able to add a persistent sheet provider, give it the name I want for the sheet, and define the sheet? Geex, the more I write what I want to do, the less I feel I grasp it. :( Basically, let me put it this way: I have DataSkins (ZClasses). I have one or two property sheets that I want most/all of the DS objects to have. I don't want to have to define the property sheet in each and every ZClass. AIUI, PersistentSheet providers can do this. I want to do it with the default ZPatterns/LoginManager includes. So, am I totally clueless, or am I just looking to hard, and missing something blatantly obvious? -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] permissions/authorization on non ZClass/product objects
I'm having trouble with permissions and Python class instances that aren't part of the Zope permission mechanism. I'm creating plain Python class instances in the Python baseclass of a ZClass, and storing them in a list on the baseclass. The baseclass instantiates these instances and appends them to its list. The class is defined in the baseclass .py file. A method on the baseclass returns this list of instances, and I'm iterating over them in DTML and looking at their attributes - or trying to. I get an authorization prompt, which always gives me an auth error, even though the user can look at the ZClass that's returning the instances. I'm able to get around this by registering the plain Python class as a base class, subclassing them with a ZClass, and instantiating ZClass instances instead of baseclass instances. It seems like overkill, though (and I always thought that instantiating ZClasses in python was confusing). I don't need to expose methods or restrict access, just open the attributes to be used as DTML variables. Are there ways to do this without making full-fledged ZClasses out of my classes? Are there guidelines in general for using non-Zopish subobjects that get used by the publishing process? -- Karl Anderson [EMAIL PROTECTED] http://www.pobox.com/~kra/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] permissions/authorization on non ZClass/productobjects
Karl, Two things come to mind: First, make sure you're returning the instances in the context of their container, e.g. instead of: def returnstuff(self): class foo: pass return foo() do def returnstuff(self): class foo: pass return foo().__of__(self) You may also want to try the magic: def returnstuff(self): class foo: __allow_access_to_unprotected_subobjects__ = 1 pass return foo().__of__(self) in the class instances you return if nothing in them needs to be protected by permissions in any way. On 2 Aug 2000, Karl Anderson wrote: > > I'm having trouble with permissions and Python class instances that > aren't part of the Zope permission mechanism. > > I'm creating plain Python class instances in the Python baseclass of a > ZClass, and storing them in a list on the baseclass. The baseclass > instantiates these instances and appends them to its list. The class > is defined in the baseclass .py file. A method on the baseclass > returns this list of instances, and I'm iterating over them in DTML > and looking at their attributes - or trying to. I get an > authorization prompt, which always gives me an auth error, even though > the user can look at the ZClass that's returning the instances. > > I'm able to get around this by registering the plain Python class as a > base class, subclassing them with a ZClass, and instantiating ZClass > instances instead of baseclass instances. It seems like overkill, > though (and I always thought that instantiating ZClasses in python was > confusing). I don't need to expose methods or restrict access, just > open the attributes to be used as DTML variables. > > Are there ways to do this without making full-fledged ZClasses out of > my classes? Are there guidelines in general for using non-Zopish > subobjects that get used by the publishing process? > > -- > Karl Anderson [EMAIL PROTECTED] http://www.pobox.com/~kra/ > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
