At 03:14 PM 9/29/00 -0500, Steve Spicklemire wrote:

Thanks so much for the response...

It turns out, I tried the Python Method and it had the same basic problem as the DTML Method... however I've now moved on, using deletageRetrieve to a new thorny issue. ;-)

When I get an object from of another specialist it appears that it doies not inherit from my specialist, but from *its* specialist. (e.g., my framework specialist has methods that I want the dataskins to acquire). I've currently got it wrapped like so:

def retrieveItem(self, key): """ get an item....""" return self.delegateRetrieve(self, None, key=key).__of__(self)

I've tried several different combinations of __of__ etc, but none of them seems to allow the dataskin to acquire, for example, standard_html_header from my specialist. Is there any way to enforce acquisition at this level?

You can use aq_base before the __of__, but I wouldn't recommend it, because you'll be forcibly ripping off security-related data. Probably aq_explicit would work better, since it would prevent default acquisition but leave security acquisitions relatively intact. I still suspect, though, that your design is not optimal. If you actually need a "bridge" specialist that lets you change the behaviors of the thing you're accessing, then you should really just build a bridge specialist and not simply do directly delegated retrieval. What you want is to set up a rack in the specialist that creates a virtual object which gets all its attributes (the ones you care about, anyway) from an object retrieved from the other specialist. SkinScript example: WITH otherSpecialist.getItem(self.id) COMPUTE theRealThing = (RESULT is None) and NOT_FOUND or RESULT WITH self.theRealThing COMPUTE myAttr1 = RESULT.theirAttr1, myAttr2 = theirAttr2, # equivalent to myAttr2 = RESULT.theirAttr2 SomeAttr, # equivalent to SomeAttr = RESULT.SomeAttr myAttr5 = theirAttr1 * theirAttr6 # Shorthand way of copying attributes with the same names WITH self.theRealThing COMPUTE foo,bar,baz You would put this in a script inside a rack in your "bridge" specialist. You would set up the rack to be "non-persistent" and use "theRealThing" as the existence attribute. Now, when you access the rack, it will create a dummy object and try to look at its "theRealThing" attribute. This will cause the SkinScript to call the other Specialist and attempt retrieval. If it succeeds, theRealThing will equal the object and the Rack will consider the object to exist in the bridge specialist. If it fails, theRealThing will be a non-existent attribute and the Rack's getItem will return None. Let's say it has succeeded. You now have an object with no attributes loaded other than 'id' and 'theRealThing'. You attempt to access attribute SomeAttr. The second SkinScript declaration fires, and computes the values of myAttr1, myAttr2, SomeAttr, and myAttr5, caching them in the DataSkin. Voila. You now have a completely transformed object, in the context of *your* specialist, with *your* attribute names. It has no leftover acquisition context, but of course you had to have permission to access all those attributes on the object and to the specialist you retrieved it from. But here's the real kicker... You determine in *your* rack the precise ZClass it will be implemented as. In effect, you have rewrapped an object's data into another class. Okay, so that works for reads. What about writes? That's a little more complex, as you'll need to write something like: STORE foo,bar USING self.theRealThing.manage_changeProperties(foo=self.foo,bar=self.bar) For whatever combinations of properties are applicable. If the properties are on a sheet, the USING expression gets more complicated. Note, too, that we could have done transformations on the 'id' to look something up, and that we could also have multiple racks, each doing transformations from different Specialists. Now, you may be asking yourself, "This all looks incredibly flexible, but is it efficient?" Hell no, of course not. You are much better off, if you have the option, of specifying to your framework's user the requirements you have for objects in that part of your system. Then, when they are designing their system, they can get the names and features right, and you call *their* specialist for what you need. If they didn't do it the easy way, then it's again *their* responsibility to re-cast your whitebox as a bridge. (Note, by the way, that if the end-user's raw data is coming from something like an SQL database in the first place, then all they have to do is map from SkinScript to SQL, and this is *much* more efficient than mapping Specialist->Rack->Specialist->Rack->SQL, which involves many more layers of object creation, method calls, and security checks.) To put it another way: design your whitebox specialist how you want it. Make it complete, but of course some parts will have to be changed if someone wants to use other than your default implementation. If they want its data to come from somewhere else, they can plug in the SkinScript or do whatever else it takes. So, to sum up... Stop worrying about delegated retrieval! :) You're stepping into app integrator territory here. ZPatterns was designed to make it easy to make reusable frameworks without hardly trying. And it was *especially* designed for retrofitting object frameworks over legacy applications and databases.

At 08:05 AM 9/30/00 -0500, Steve Spicklemire wrote:

I'd hate to find out later that someone needs to go in and edit my Python code to make my framework useable.... But.. I think what I'm hearing is that working out the integration at the Rack level is much better than trying to delgate retrieval at the Specialist level. I'm not sure where I got the idea that delegating retrieval at the Specialist level was the 'right' way, maybe in the Drop Zone example? Anyway... thanks again for your reply. I'll

You might have gotten it from there, in that the example doesn't get into any detail of *how* retrieval gets delegated. There are many ways to delegate retrieval, but direct delegation is only useful in the case where the thing you're delegating to already has the interface you want. In the example, it was assumed that the SkyDiver implemented the interfaces needed by the different black-box frameworks being re-used, and therefore delegated retrieval would have been the appropriate customization of the white-box specialists. The point, however, is that it's the application integrator's job to rip up your white-boxes in whatever way it takes to do the integration. Again, if they have built their crossover class (e.g. SkyDiver) according to the interface required by the white-boxes, then their customizations are trivial. If not, then they must do more work. If you want to make sure that someone needn't edit Python code, all you have to do is ensure that your Specialist never does any data manipulation except through altering attributes or propertysheets on a DataSkin, and that any multi-item methods (e.g. search methods) are TTW-overrideable methods (using the __replaceable__ property in your Python code). Then, the integrator can override those methods with SQL queries or catalog queries or whatever, and they can script the mappings of the DataSkin's attributes into whatever behavior they want.

march happily along now and see what I run into next! ;-) (I'm especially grateful for your explaination of using a virtual object (non-persistent) in a Rack. I've not seen that explained so clearly anywhere else.. and I'm going to use it!

Great. By the way, that is also how one makes a rack that retrieves objects from an SQL or LDAP database. You do a WITH/COMPUTE on the query that retrieves the record and maps it into the attributes you want. The latest version of SkinScript (not yet released) now has a QUERY keyword that makes use of SQL/LDAP queries easier, as you can do: WITH QUERY someSQLMethod(key=self.id) COMPUTE foo,bar,baz instead of having to do this junk: WITH (someSQLMethod(key=self.id) or [NOT_FOUND])[0] COMPUTE foo,bar,baz There is also now an OTHERWISE LET clause for WITH/COMPUTE that lets you specify default values in case the query doesn't find a record. These and a few other new SkinScript clauses should be out in 0.4.3, sometime mid-October. Ty and I have also developed some advanced tricks to allow an SQL database to refer to objects which are in LDAP or the ZODB, allowing one to store different parts of your data in databases which have the best performance or handling characteristics for that kind of data. However, to use these tricks you must specifically design your SQL database for the purpose. It's not terribly tricky, but it's a whole 'nother pattern language of its own, and we're not ready to "publish" yet. Especially since at this stage it'll be just another thing we've invented but not thoroughly documented for others to take advantage of. :(

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...

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