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.