So let's start throwing some brute force hacking at the problem! ;-) >> From a mail about the LinuxTag conference: >> P.S. ABout ZPatterns: everyone I spoke to was thought the basic >> idea behind ZPattern was good and sound and nice and so on. But >> _everyone_ complained about it being too pretentious (with all >> the computer science claims and theory behind it) and >> introducing too many unnecessary new concepts (racks, >> specialist and what have you). All this is very distracting. I >> for one can't get my head around it. But that seems to be what >> you're saying as well. Seriously, I'm trying to get it all figured out, and I thought maybe if I attempted to do something 'real' with it I would at least learn what I *don't* understand. Well.. I've learned a *lot*! (about what I don't understand.. ) ;-) The source code is astonishingly simple looking, but about one layer deeper that I can easily grok, apparently. I have a site that displays data from a database. Customers want to include this data on their web site, say as an included 'frame'. Each customer wants a slightly different slice of the data, and of course they want it all dressed up in the correct 'look' so that it appears seamlessly integrated. I create a "View" ZClass, subclass of DataSkin, that looks at the data with the perspective if a customer. It should keep track of all the information about how a particular site wants the results to look, and what data is interesting. I make a PropertySheet in my ZClass called 'Basic', in which I keep the basic properties I need to track the necessary information. To go along with this, I create an instance of a Specialist called "viewManager" who has a (default) rack of "View" objects. I also create a "TableInfo" ZClass, subclass of DataSkin, that quantifies the kind of data the customers have to choose from, and metadata about the data (headers, query parameters and suchlike). I create a ZClass property sheet for the TableInfo ZClass. Finally I create an instance of Specialist (tableManager) with a (default) rack of TableInfo objects. Now... some of the Tableinfo properties, and some of the View properties are *really* in MySQL. I figured out, from the mail list and the source code, that I can create a Generic attribute provider in the rack that can get attributes from an SQL database for my DataSkin descendents using the 'source expression' and 'target expression' business. e.g., Source expression: (GetTableInfo(tableInfoID=self.id) or [NOT_FOUND])[0] Target expressions: tableHeaders=RESULT.tableHeaders footnote=RESULT.footnote and when I ask one of my TableInfo instances for their footnote it comes right out of MySQL! Cool. Now.. I can't seem to figure out how to *change* the data in the database when the user 'edits' the DataSkin.... which brings up the whole issue of changing stuff in DataSkins. Even when I can figure out *a* way to make it work.. I'm almost sure it's not *the* way it should work. The problem I'm having is that I feel that some of my code is violating Demeter... and it makes me think that I'm still missing some really fundamental insight... For example: My tableManagerr has a method like this, the "addNewTableInfo" method: <dtml-var standard_html_header> <center> <h2> Inserting new Data Table Info Item!</h2> <dtml-let ni="newItem(name)" nips="ni.propertysheets.get('Basic')"> <dtml-call "nips.manage_changeProperties(REQUEST)"> </dtml-let> <form action=index_html> <input type=submit value="OK"> </form> </center> <dtml-var standard_html_footer> Now... I thought that stuff like: nips="ni.propertysheets.get('Basic')"> was a "nono" on Demeter grounds... I *should* be able to say simply: ni.setAllTheRightThings(REQUEST) But I can't seem to find that method in the source. ;-) Or is it that Specialists are allowed to have special 'inside' knowledge about the objects they specialize in, since they are, after all, specialists! Also.. I've gotten the habit of adding methods to my ZClasses that edit themselves: editInstance: <dtml-var standard_html_header> <center> <dtml-call "propertysheets.get('Basic').manage_changeProperties(REQUEST=REQUEST)"> Table Info Changed.<br> <form action="&dtml-URL2;"> <input type=submit value="OK"> </form> </center> <dtml-var standard_html_footer> But this won't work now... since I could add another propertysheet in the Specialist. Should the specialist call manage_changeProperties on all the propertysheets? (including any defined in the ZClass) Is there some method hidden somewhere that does this? Anyway.. this is what I'm working on at the moment... Any insight appreciated... since I seem to be having a shortage. ;-) -steve