Hi Steve, I've made my experiment simple, by playing with the DumbZPatterns examples, testing one rack under one specialist. Here is the skinscript: WITH Deliverables.getItem(self.id) COMPUTE name=name, dueDate=dueDate, description=description, todoIDs=todoIDs WITH SELF COMPUTE name=name, dueDate='1973/01/01', description='unknown achee', todoIDs=[] The virtual instance is loaded by accessing attribute of 'name'. I thought any calls for inexistent objects in Deliverables would turn out default values. Yet the test result turned out an not_found error. The following modification (change to 'otherwise' clause) didn't make a difference: WITH Deliverables.getItem(self.id) COMPUTE name=name, dueDate=dueDate, description=description, todoIDs=todoIDs OTHERWISE LET name='unknown', dueDate='1973/01/01', description='unknown achee', todoIDs=[] One more question, i.e. the following expression WITH Deliverables.getItem(self.id) COMPUTE name, dueDate, description, todoIDs also trigered the 'not_known' error for every objects in Deliverables. Where goes wrong? Dirksen __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Hi Dirksen, To which specialist did you make this change? and did you make any other changes? Also.... (I'm sure this is obvious and I'm really just confirming what I'm already sure you've checked..) is there an item in the Deliverable's rack with the id you checked? thanks, -steve
Hi Dirksen, Did you say you were using 0.4.3b1 or b2? I think that this sounds like the bug from b1: http://lists.zope.org/pipermail/zope-dev/2000-October/007650.html -steve
"Dirksen" == Dirksen <dirksen_lau@yahoo.com> writes:
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
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 )
Hi Dirksen, OK.. the problem was that DataSkinAddons:DummyDataSkin doesn't allow access to attributes of 'self'. Once I switched to a differnt ZClass (which is a direct subclass of DataSkin) then everything was fine again.. ) just for Facade instances: I'm now using WITH Deliverables.getItem(self.id) COMPUTE originalObject=RESULT or NOT_FOUND with 'loaded by accessing attribute' set to 'originalObject' and WITH self.originalObject COMPUTE myName=name, myDescription=description, dueDate then in the FacadeClass index_html: <dtml-var standard_html_header> I am a facade! <dtml-var myName> <hr> Description:<dtml-var myDescription><br> <hr> I'm due: <dtml-var dueDate> <dtml-var standard_html_footer> and all is working OK. What ZClass are you using for your instances? -steve
"Steve" == Steve Spicklemire <steve@spvi.com> writes:
Steve> Hi Dirksen, Steve> Hmm.. this is starting to look like a bug. I tried the same Steve> thing with the ZPatterns example. I have a real site using Steve> this technique with ZPatterns-0.4.2a?? and it's working, Steve> so it's probably something introduced in 0.4.3. Here's what Steve> I did: Steve> I created a new Specialist 'Facade' with a Steve> DataSkinAddons:DummyDataSkin as it's storage class and Steve> 'originalObject' as the attribute to check for existence. Steve> Then I put in the following SkinScript: Steve> WITH Deliverables.getItem(self.id) COMPUTE Steve> originalObject=(RESULT is _.None) and NOT_FOUND or RESULT Steve> WITH self.originalObject COMPUTE name Steve> and ran in 'debug mode.' I get the following traceback on Steve> the console when I try to access a known deliverable Steve> through the Facade Specialist: Steve> Traceback (innermost last): File Steve> /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/AttributeProviders.py, Steve> line 304, in _AttributeFor (Object: GAPMixin) File Steve> /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/Expressions.py, Steve> line 122, in eval File Steve> /usr/local/etc/Zope2a/lib/python/DocumentTemplate/DT_Util.py, Steve> line 337, in eval (Object: Deliverables . getItem ( self Steve> . id )) (Info: Deliverables) File <string>, line 0, in ? Steve> File Steve> /usr/local/etc/Zope2a/lib/python/DocumentTemplate/DT_Util.py, Steve> line 140, in careful_getattr File Steve> /usr/local/etc/Zope2a/lib/python/Products/ZPatterns/Expressions.py, Steve> line 53, in validate File Steve> /usr/local/etc/Zope2a/lib/python/AccessControl/SecurityManager.py, Steve> line 139, in validate File Steve> /usr/local/etc/Zope2a/lib/python/AccessControl/ZopeSecurityPolicy.py, Steve> line 159, in validate Unauthorized: id Steve> I tried stepping through with the debugger... but got lost Steve> in the details of the GAP evaluator. I'll try again after Steve> breakfast and see what I can come up with. Steve> ;-) Steve> Look on the bright side. You're making ZPatterns a better Steve> product. Steve> -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 ) Steve> _______________________________________________ Zope Steve> maillist - Zope@zope.org Steve> http://lists.zope.org/mailman/listinfo/zope ** No cross Steve> posts or HTML encoding! ** (Related lists - Steve> http://lists.zope.org/mailman/listinfo/zope-announce Steve> http://lists.zope.org/mailman/listinfo/zope-dev )
Hi Dirksen, For your 'otherwise' case, could you have a single instance that serves as an 'unknown' object: WITH Deliverables.getItem(self.id) COMPUTE originalObject=RESULT or NOT_FOUND OTHERWISE originalObject=Deliverables.getItem('Unknown') where it is known that the Deliverables Specialist has an instance with id='Unknown'. The problem with OTHERWISE is that it only works within the context of a single WITH/COMPUTE, and if you don't get 'originalObject' then your WITH/COMPUTE will never fire. -steve
"Dirksen" == Dirksen <dirksen_lau@yahoo.com> writes:
Dirksen> Hi Steve, Dirksen> The first thing is, my ZPatterns' version was Dirksen> 0.4.3.b1. So I quickly downloaded b2, which passed my Dirksen> nameorassignlist, but still didn't fixed the fail-through Dirksen> problem. Dirksen> The 2nd thing is, your script turned out just fine in my Dirksen> case when calling existent deliverable objects. It just Dirksen> didn't fail-through, not even the 'otherwise' clause is Dirksen> applied. This is weird! Dirksen> cheers Dirksen
participants (2)
-
Dirksen -
Steve Spicklemire