Hi Dirksen, Hmm.. this is starting to look like a bug. I tried the same thing with the ZPatterns example. I have a real site using this technique with ZPatterns-0.4.2a?? and it's working, so it's probably something introduced in 0.4.3. Here's what I did: I created a new Specialist 'Facade' with a DataSkinAddons:DummyDataSkin as it's storage class and 'originalObject' as the attribute to check for existence. Then I put in the following SkinScript: WITH Deliverables.getItem(self.id) COMPUTE originalObject=(RESULT is _.None) and NOT_FOUND or RESULT WITH self.originalObject COMPUTE name and ran in 'debug mode.' I get the following traceback on the console when I try to access a known deliverable through the Facade Specialist: Traceback (innermost last): File /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/AttributeProviders.py, line 304, in _AttributeFor (Object: GAPMixin) File /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/Expressions.py, line 122, in eval File /usr/local/etc/Zope2a/lib/python/DocumentTemplate/DT_Util.py, line 337, in eval (Object: Deliverables . getItem ( self . id )) (Info: Deliverables) File <string>, line 0, in ? File /usr/local/etc/Zope2a/lib/python/DocumentTemplate/DT_Util.py, line 140, in careful_getattr File /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/Expressions.py, line 53, in validate File /usr/local/etc/Zope2a/lib/python/AccessControl/SecurityManager.py, line 139, in validate File /usr/local/etc/Zope2a/lib/python/AccessControl/ZopeSecurityPolicy.py, line 159, in validate Unauthorized: id I tried stepping through with the debugger... but got lost in the details of the GAP evaluator. I'll try again after breakfast and see what I can come up with. ;-) Look on the bright side. You're making ZPatterns a better product. -steve
"Dirksen" == Dirksen <dirksen_lau@yahoo.com> writes:
Dirksen> Hi Steve, Dirksen> I've made my experiment simple, by playing with the Dirksen> DumbZPatterns examples, testing one rack under one Dirksen> specialist. Here is the skinscript: Dirksen> WITH Deliverables.getItem(self.id) COMPUTE name=name, Dirksen> dueDate=dueDate, description=description, todoIDs=todoIDs Dirksen> WITH SELF COMPUTE name=name, dueDate='1973/01/01', Dirksen> description='unknown achee', todoIDs=[] Dirksen> The virtual instance is loaded by accessing attribute of Dirksen> 'name'. I thought any calls for inexistent objects in Dirksen> Deliverables would turn out default values. Yet the test Dirksen> result turned out an not_found error. The following Dirksen> modification (change to 'otherwise' clause) didn't make a Dirksen> difference: Dirksen> WITH Deliverables.getItem(self.id) COMPUTE name=name, Dirksen> dueDate=dueDate, description=description, todoIDs=todoIDs Dirksen> OTHERWISE LET name='unknown', dueDate='1973/01/01', Dirksen> description='unknown achee', todoIDs=[] Dirksen> One more question, i.e. the following expression WITH Dirksen> Deliverables.getItem(self.id) COMPUTE name, dueDate, Dirksen> description, todoIDs Dirksen> also trigered the 'not_known' error for every objects in Dirksen> Deliverables. Where goes wrong? Dirksen> Dirksen Dirksen> __________________________________________________ Do You Dirksen> Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions Dirksen> of Products. http://shopping.yahoo.com/ Dirksen> _______________________________________________ Zope Dirksen> maillist - Zope@zope.org Dirksen> http://lists.zope.org/mailman/listinfo/zope ** No cross Dirksen> posts or HTML encoding! ** (Related lists - Dirksen> http://lists.zope.org/mailman/listinfo/zope-announce Dirksen> http://lists.zope.org/mailman/listinfo/zope-dev )