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

Steve Spicklemire steve@spvi.com
Fri, 22 Dec 2000 08:40:36 -0500 (EST)


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 )