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.
HTH, Chris
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
At 10:06 AM 7/3/00 -0500, Steve Spicklemire wrote:
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.
That's an unfortunate side-effect of applying Demeter's law... it's easy to grasp (in an abstract way) local implementation aspects, but hard to grasp how the actual *concrete* implementation works from looking at the pieces. It's the "there's no *there* there" effect, as Ty dubbed it.
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.
Congratulations, you found the top secret documentation. :)
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.
Here's some more top-secret documentation... Use a GenericTrigger to implement attribute changes. Set up your trigger to be activated on object changes, and set the trigger expression to call an SQL method, e.g.: UpdateTableInfo(object=self,CHANGED=CHANGED) In the SQL method, code something like this: UPDATE mytable SET <dtml-if "CHANGED('attr1')"> attr1=<dtml-var "object.attr1">, </dtml-if> ... WHERE primary_key='<dtml-var "object.id" sql_quote>' with an "if" block for each attribute you might want to update. Last part, and this is the trick that's not yet documented... set the "Set Attrs" field to be a list of the attributes you want the trigger to handle set/delete operations for. (You don't need to put anything in the "Keeping" field unless you need a "before" value of an expression to use in your SQL.)
Thus spake Phillip J. Eby (pje@telecommunity.com):
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
Here's some more top-secret documentation... Use a GenericTrigger to implement attribute changes. Set up your trigger to be activated on object changes, and set the trigger expression to call an SQL method, e.g.:
First off it is amazing what a rush it is to fight ZPatterns, and finualy start winning. <g> Anyway, Under Zope 2.2, the 'Upon' property of a trigger doesn't have a list of 'event_kinds'. I think this is related to an earlier post where i complained about zope 2.2 not being able to get such values (for select types) from aquisition, or in this case from a seperate property in its class. Has anybody thought of a way to address this problem, as it didn't sound like the official zope distribution wants to act the way that would allow the 'Upon' property to get its proper values right now. (no, i'm not going to go off about that <g>) Also, should i not be trying to use ZPatterns 4aX under Zope 2.2? I thought i read that to use triggers a person should use Zope 2.2, but it doesn't appear this has been tested under 2.2. (although it is alpha, i haven't forgotten that) ZPatterns is starting to taste pretty sweet. Keep up the good work! sRp -- Scott Parish http://srparish.net/
At 03:10 AM 7/6/00 +0000, Scott Parish wrote:
Anyway, Under Zope 2.2, the 'Upon' property of a trigger doesn't have a list of 'event_kinds'. I think this is related to an earlier post where i complained about zope 2.2 not being able to get such values (for select types) from aquisition, or in this case from a seperate property in its class. Has anybody thought of a way to address this problem, as it didn't sound like the official zope distribution wants to act the way that would allow the 'Upon' property to get its proper values right now. (no, i'm not going to go off about that <g>)
In our working copy of ZPatterns, Ty has patched ZPatterns to make the list a property. Personally, I think this recent behavior of 2.2 is broken, and I hope to submit a patch soon to the Collector to fix it, so that we can back out the ZPatterns patch. It should not be necessary for the value of a select/multiselect property to be another *property*, as this will break other people's code besides ZPatterns. The Zope documentation in OFS/PropertyManager.py explicitly states: For 'selection' and 'multiple selection' properties, there is an addition item in the property dictionay, 'select_variable' which provides the name of a property or method which returns a list of strings from which the selection(s) can be chosen. So this is pretty clearly broken in 2.2.
Also, should i not be trying to use ZPatterns 4aX under Zope 2.2? I thought i read that to use triggers a person should use Zope 2.2, but it doesn't appear this has been tested under 2.2. (although it is alpha, i haven't forgotten that)
Yeah, you can use it under 2.2, although as you've pointed out, there is a problem with the property issue. It has been tested rather extensively under 2.2, it's just that this one item hasn't been put out in a fix release, because we were going to report it to the Collector as a bug (I'm not sure if Ty has done so yet; it was right before my vacation that he found the problem). As for the warning about transactional issues with triggers under 2.1.x, they have to do with triggers that update things stored in the ZODB, and they will not always have problems. It's just that transaction ordering semantics are very different between 2.1.x and 2.2; 2.2 is pure FIFO where 2.1.x is a LIFO stack, even during the commit process.
ZPatterns is starting to taste pretty sweet. Keep up the good work!
Thanks.
participants (4)
-
Chris Withers -
Phillip J. Eby -
Scott Parish -
Steve Spicklemire