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