[Zope] How to make two racks work under one specialist?

[Steve Spicklemire]

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 )