[Zope-dev] More comments on ZPatterns

[Steve Spicklemire]

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