[Zope-dev] Success! Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists? Specialists?

[Steve Spicklemire]

Yes.. I see what you mean... this is a 'whitebox customization' 
that I used as part of the integration of my framework into
the 'online catalog' system. This is not 'blackbox' code that
is integral to my system.... 

In fact, I mis-spoke earlier, it's not in my specialist at all... it
only appears in a method of a ZClass that I use as the 'storage class'
for objects controlled by one of my specialists.... this is clearly
whitebox territory, since this wrapper is chosen by the
integrator... The first thing my docs (will) say to do.. is go through all
my specialists and choose 'storage' classes for each specialist.

This brings up another point.... If I choose 'DataSkin' as a storage
class, then my code hits the security system every time a refer
to any data (simple types) stored directly in the DataSkin. I can either
set __allow_access_to_unprotected_subobjects=1 on each instance,
or I can write accessor methods for each attribute, (yuk!, but
maybe good in some ways...) or I can ask the integrator to create
'dummy' ZClass(es) even for those racks that they don't want/need
to customize (which seems to 'get around' the security system.)
I'm curious to know what you folks do here.. do you write accessor
methods for every type stored in your DataSkins?

Anyway.. thanks for the great tools! I'm having fun now. ;-)

-steve

>>>>> "Phillip" == Phillip J Eby <pje@telecommunity.com> writes:

    Phillip> At 09:15 PM 10/4/00 -0500, Steve Spicklemire wrote:
    >>  This was also nice since in my Specialist I could do things
    >> like:
    >> 
    >> <dtml-call
    >> "RESPONSE.redirect(this().theRealThing.absolute_url())">
    >> 
    >> After the user is finished working in my 'app area' they could
    >> get redirected back to the actual object that my Specialist was
    >> 'posing' for...

    Phillip> I don't really recommend the above, unless it's being
    Phillip> done by SkinScript.  Otherwise, you're unnecessarily
    Phillip> exposing an implementation attribute (theRealThing).
    Phillip> Instead, require that your object implement a redirect()
    Phillip> method, and define it in the class as
    Phillip> "class_default_for_redirect".  Then you can override the
    Phillip> method in SkinScript or with a class extender (a new
    Phillip> 0.4.3 feature).  Doing it this way means your framework
    Phillip> code will not incorporate an assumption that your
    Phillip> whitebox specialist is always going to be wrapping
    Phillip> someone else's objects.