[Zope-dev] More comments on ZPatterns
>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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
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:
Inserting new Data Table Info Item!
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:
Table Info Changed.
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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
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 attr1=, ... WHERE primary_key='' 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.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
Thus spake Phillip J. Eby ([EMAIL PROTECTED]): > >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. 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 ) 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/ PGP signature
Re: [Zope-dev] More comments on ZPatterns
At 03:10 AM 7/6/00 +, 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 ) 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
> "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes: >> 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. pje> Congratulations, you found the top secret documentation. :) That's what I love about working with ZPatterns. You get to play all sorts of "Roles" as a developer... part "James Bond", part "Hercule Poirot", part "Bumbling Imbecile". ;-) I've heard that it's "Roles before Objects" but I had no idea it would be like this! Here's one I've been feeling kinda stupid about: >Now, "SkyDiver ... *used as*" means we should: > > 1. subclass (not a good choice) > 2. implement interface >2.1. by copying and pasting methods code (or whole methoids) >2.2. by proxiyng (SkyDiver has a references to actual Customer > and ResourceUser) >2.3. by transmitting messages to SkyDiverSpecialist which will pass > unhandled messages to CustomerSpecialist and > ResourceUserSpecialist (this is a variant of 2.2. case) > >The 2.3. case means we should use objects without types (identity >markers). pje> None of the above. SkyDiver should inherit from a Party base class. For pje> Customer and ResourceUser behavior, one adds propertysheets whose class is pje> provided by the respective frameworks. This is extension through pje> *composition*, rather than inheritance. It is similar to the COM approach, pje> where you can ask an object to give you a pointer to an interface. In this pje> approach, you ask for a propertysheet that provides the interface. "One adds propertysheets" is much easier said than done... IMHO. The only way I've seen to add propertysheets to objects is to call manage_addPropertySheet on individual instances... as described in this earlier email: pje> pje> This isn't exactly code, but... pje> pje> Set up a LoginManager with a GenericUserSource, and set up the GUS to have pje> users. Make sure that the GUS has a "Persistent Sheet Provider" on the pje> "Sheet Providers" tab. Then go to: pje> pje> /acl_users/someuser/propertysheets/manage_addPropertySheet?id=sheetname&ns= pje> pje> You should get a screen that says "OK". pje> pje> Then go to: pje> pje> /acl_users/someuser/propertysheets/sheetname/manage pje> pje> And you should see a propertysheet editor for your new sheet. pje> (Unfortunately, it won't let you edit anything unless your user class is pje> based on PropertyManager, due to an oversight in ZPatterns 0.3.0; the pje> VirtualSheets class needs "def propertyLabel(self,id): return id" to work pje> with the default Zope UI for a non-ZClass property sheet.) pje> pje> Or go to: pje> pje> /acl_users/someuser/propertysheets/manage pje> pje> And you should see your new propertysheet listed on the sheets management pje> interface (which is somewhat broken, but that's because the basic one in pje> Zope is, it's not ZPatterns' fault. ;) ) pje> pje> Anyway, this is all very primitive but should get better in later versions. pje> 0.4.0 fixes the 0.3.0 and either it or 0.5.0 will replace the broken pje> propertysheets/manage screen with one that will let you add/edit/delete pje> sheets properly. I just want to make sure I understand... is the intention that property management needs to be done on each instance separately? So if I add a new property to one of my property sheets, I need to somehow update the propertysheets of each of the instances? Also if I need to create propertysheets for each instance... where should that be done? I suppose it makes sense to put that in the Specialist that handles the object that gets the properties?...no? thanks, -steve ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
Steve Spicklemire wrote: > > I just want to make sure I understand... is the intention that property management > needs to be done on each instance separately? So if I add a new property to one > of my property sheets, I need to somehow update the propertysheets of each of the > instances? Also if I need to create propertysheets for each instance... where > should that be done? I suppose it makes sense to put that in the Specialist that > handles the object that gets the properties?...no? No need for all that. Your instances are DataSkins, and they get their PropertySheets via an InjectionFolder. All you need to do is tell a DataManager that is in an appropriate InjectionFolder that it should handle DataSkins of whatever meta_type your instances have. Furthermore, configure this DataManager to provide the PropertySheets you want, with sensible default values, and suddenly, all your instances suport this propertysheet. An "appropriate InjectionFolder" is one that lies in the acquisition path of your instances. [postscript: I only realized this stuff a couple of days ago, when I started using ZPatterns on a project :-) ] -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
At 12:38 PM 7/9/00 -0500, Steve Spicklemire wrote: > >pje> None of the above. SkyDiver should inherit from a Party base class. For >pje> Customer and ResourceUser behavior, one adds propertysheets whose class is >pje> provided by the respective frameworks. This is extension through >pje> *composition*, rather than inheritance. It is similar to the COM approach, >pje> where you can ask an object to give you a pointer to an interface. In this >pje> approach, you ask for a propertysheet that provides the interface. > >"One adds propertysheets" is much easier said than done... IMHO. The only way >I've seen to add propertysheets to objects is to call manage_addPropertySheet >on individual instances... as described in this earlier email: That's the only way that's implemented "out of the box". But there's no reason you can't implement a SheetProvider that automatically creates the sheet when the object is added, or why you can't use a GenericTrigger to add the sheet using one of the out-of-the-box SheetProviders. When I get SkinScript objects done, this'll be easier because you'll be able to just spec out a propertysheet in SkinScript and have the dirty work done for you. >I just want to make sure I understand... is the intention that property management >needs to be done on each instance separately? So if I add a new property to one >of my property sheets, I need to somehow update the propertysheets of each of the >instances? Also if I need to create propertysheets for each instance... where >should that be done? I suppose it makes sense to put that in the Specialist that >handles the object that gets the properties?...no? The intention is that you use SheetProviders for anything global. Adding propertysheets on an instance-by-instance basis is something that's intended for an interface point between two frameworks. Say for example you have a project scheduling framework that needs to store a due date associated with a document -- the scheduling system can query for a scheduling propertysheet, and if it doesn't exist, add it. However, since you control what SheetProvider implements that propertysheet, you can (for example) use the same SQL database for all scheduling fields across your site. If you don't need special handling, however, you can leave the default "Persistent" SheetProvider in place and the scheduling properties would get stored persistently. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
Thanks Steve, Eegads! OK... all my instances currently live in a defaultRack of one specialist or another... so exactly how do I "configure this DataManager to provide the PropertySheets (I) want, with sensible default values, and suddenly, all (my) instances suport this propertysheet." I think this is the step I'm missing. I seem to be able to fiddle with "Data Plug-ins" all day long.. I can create "Persistant Sheet Providers" and type all sorts of stuff into various boxes and they never magically seem to behave the way your are describing... so either I'm missing some basic concept or it doesn't really work that way! ;-) thanks! -steve > "Steve" == Steve Alexander <[EMAIL PROTECTED]> writes: Steve> Steve Spicklemire wrote: >> I just want to make sure I understand... is the intention that >> property management needs to be done on each instance >> separately? So if I add a new property to one of my property >> sheets, I need to somehow update the propertysheets of each of >> the instances? Also if I need to create propertysheets for >> each instance... where should that be done? I suppose it makes >> sense to put that in the Specialist that handles the object >> that gets the properties?...no? Steve> No need for all that. Steve> Your instances are DataSkins, and they get their Steve> PropertySheets via an InjectionFolder. Steve> All you need to do is tell a DataManager that is in an Steve> appropriate InjectionFolder that it should handle DataSkins Steve> of whatever meta_type your instances have. Furthermore, Steve> configure this DataManager to provide the PropertySheets Steve> you want, with sensible default values, and suddenly, all Steve> your instances suport this propertysheet. Steve> An "appropriate InjectionFolder" is one that lies in the Steve> acquisition path of your instances. Steve> [postscript: I only realized this stuff a couple of days Steve> ago, when I started using ZPatterns on a project :-) ] Steve> -- Steve Alexander Software Engineer Cat-Box limited Steve> http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
At 01:37 PM 7/9/00 -0500, Steve Spicklemire wrote: > >Thanks Steve, > >Eegads! OK... all my instances currently live in a defaultRack of one >specialist or another... so exactly how do I "configure this >DataManager to provide the PropertySheets (I) want, with sensible >default values, and suddenly, all (my) instances suport this >propertysheet." I think this is the step I'm missing. I seem to be >able to fiddle with "Data Plug-ins" all day long.. I can create >"Persistant Sheet Providers" and type all sorts of stuff into various >boxes and they never magically seem to behave the way your are >describing... so either I'm missing some basic concept or it >doesn't really work that way! > It doesn't *quite* work that way. As mentioned in my e-mail, if you want the sheets to already exist, you'll need to either create a custom SheetProvider in Python, or you'll need to use a GenericTrigger to add them when objects are added (which won't help you when you want to add a new sheet after the fact). Now, if you're designing a new project, as Steve A. was, then of course you can set things up cleanly from the start. Globally adding sheets at a later point currently requires a custom provider, but should be doable with a later version of ZPatterns just by writing the SkinScript for the new sheet(s). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
Wow.. alright. I think I need "ZPatterns for Dummies" or maybe there
needs to be a disclaimer "ZPatterns are NOT for Dummies." ;-)
I've pretty much given up on Sheets for now. Nothing I've tried
has actually worked. I thought maybe I needed to switch to 2.2,
but then all the code that *was working* stopped working...
(e.g., I would get permission errors when I tried things
like "ni=newItem('foo')"... "ni.propertysheets.get('Basic')"
'get' is disallowed... in 2.2 somehow.. "Basic" is a propertysheet
defined in the ZClass for my instances.)
Maybe someone could just say, in a plain, step-by-stepish sort of way,
how to add/delete/etc sheet providers for a pure ZClass based object
at any time at all. (I would be happy to start over, if I felt I knew
what I was doing!)
Anyway... I went back to 2.1.6 and finally got triggers working. I
thought I would share a minor success and ask the ZPatterns gurus if
this is 'right' so that I might not go too far down the 'wrong' road!
I defined a Generic Trigger in my defaultRack's Data Plugins
that managed the same attributes that I have defined in
my "Generic Attribute Provider" in the same Rack, for the
same instances. The only persistan attribute is the id of
the object, which turns out to be the primary key of a single table
in MySQL that I use for my SQL based attributes. My Generic Trigger
has
Execute: updateTypes(object=self, CHANGED=CHANGED)
and
setattrs: "attrib1 attrib2 ..."
my 'updateTypes' method is a ZSQL method that talks to the MySQL
database. It has arguments:
object CHANGED
and a body like:
UPDATE mytable SET
attrib1='',
attrib2='',
.
.
.
attribN=''
WHERE id=''
(I had to make the last attribute unconditionally set
since otherwise the extra comma created an SQL syntax
error if it was excluded... could sqlgroup fix this?)
My only problem was that I couldn't trigger the trigger!
In the past I've always called manage_changeProperties to
adjust an ZClass's properties. But since only the ID is
stored persistently... that doesn't make any sense. Instead
I ended up creating an external method:
--
import string
def setObjectAttrs(self, object, attrs):
attrList = []
for k in attrs.keys():
if hasattr(object, k):
setattr(object, k, attrs[k])
attrList.append(k)
return "Updated attributes " + string.join(attrList, ',') + "." + " Orig attrs: "
+ `attrs` + "."
--
to set my object attributes. I then created a method called
"editInstance" like this:
Table Info Changed.
--
That called the external method to actually trigger the "Generic Trigger".
It did work... I can't help but wonder if I missed some obvious
and much simpler way to accomplish this! Since these are 'pure ZClass'
objects.. an external method seems like the easiest way to go. For
my Python based objects.. I suppose it makes more sense to use
a method of the object itself, but there I want to be able to
have the object handle attributes that I haven't thought of yet! ;-)
Anyway.. feedback appreciated.
Back to the trenches for this dummy. ;-)
-steve
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
Phillip, What if the management interface for specialists provided a way to manipulate, or at least view, the table of virtual objects (or, in ZPatterns-speak, DataSkins)? Wouldn't that make ZPatterns more accessible? Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
At 04:40 PM 7/9/00 -0500, Steve Spicklemire wrote:
>
>Wow.. alright. I think I need "ZPatterns for Dummies" or maybe there
>needs to be a disclaimer "ZPatterns are NOT for Dummies." ;-)
>
>I've pretty much given up on Sheets for now. Nothing I've tried
>has actually worked. I thought maybe I needed to switch to 2.2,
>but then all the code that *was working* stopped working...
It's possible that something *is* broken. Ty and I are not yet using
ZPatterns-based propertysheets for production work, and anything we don't
use yet for production work isn't as thoroughly tested.
>(e.g., I would get permission errors when I tried things
>like "ni=newItem('foo')"... "ni.propertysheets.get('Basic')"
>'get' is disallowed... in 2.2 somehow.. "Basic" is a propertysheet
>defined in the ZClass for my instances.)
This appears to be a Zope bug; OFS.PropertySheets.PropertySheets does not
define roles/permissions for the "get" method. This should probably be put
in the Collector.
>Maybe someone could just say, in a plain, step-by-stepish sort of way,
>how to add/delete/etc sheet providers for a pure ZClass based object
>at any time at all. (I would be happy to start over, if I felt I knew
>what I was doing!)
I'm not sure what you're asking for here; I thought you previously quoted
from an explanation of how to do that.
>Anyway... I went back to 2.1.6 and finally got triggers working. I
>thought I would share a minor success and ask the ZPatterns gurus if
>this is 'right' so that I might not go too far down the 'wrong' road!
>
>I defined a Generic Trigger in my defaultRack's Data Plugins
>that managed the same attributes that I have defined in
>my "Generic Attribute Provider" in the same Rack, for the
>same instances. The only persistan attribute is the id of
>the object, which turns out to be the primary key of a single table
>in MySQL that I use for my SQL based attributes. My Generic Trigger
>has
You don't need "id" to be persistent, if all it's for is to map to the SQL
database. Just make sure your GAP returns NOT_FOUND (if the record doesn't
exist) for some attribute you can then use as your "load attribute" on the
Storage Settings tab of the Rack. (If you were keeping "id" persistent so
that you could use the getPersistentItemIds() method, note that you can use
an SQL method for that purpose instead.)
>(I had to make the last attribute unconditionally set
>since otherwise the extra comma created an SQL syntax
>error if it was excluded... could sqlgroup fix this?)
No, but you could use the CHANGED_ATTRS() function instead and use an "in"
loop. CHANGED_ATTRS() returns the list of attribute names which were set
or deleted during the transaction. You could then use:
,
to add the comma between SET clauses. You would still, of course have to
do conditional code for the types of your variables.
>My only problem was that I couldn't trigger the trigger!
>In the past I've always called manage_changeProperties to
>adjust an ZClass's properties. But since only the ID is
>stored persistently... that doesn't make any sense. Instead
>I ended up creating an external method:
manage_changeProperties is an ideal way to change the attributes, actually.
The only problem is that a "common instance property sheet" won't work, as
Ty and I found out last week when we tried to build a production app using
GAP's and GenericTriggers.
The problem is that when a default attribute is set on the ZClass,
__getattr__ doesn't get called on the instances for that attribute, so you
can never get the value from your database. You can change the properties
all you want, and your database will be updated, but you'll still never see
the data in Zope.
So I've added a new kind of property sheet, a "DataSkin Property Sheet",
which sets default attributes as "class_default_for_X" names in the ZClass.
DataSkins already support defaulting to class_default_for_X if an
attribute provider doesn't come up with something, so it works out quite
well. Trick is, I haven't released this new feature yet; I only added it
Thursday evening and there are some other unfinished bits as yet.
The approach you took, with external methods, is the approach Ty took as a
workaround until I got DataSkin Property Sheets together, and is a
reasonable way to deal with it for now.
>That called the external method to actually trigger the "Generic Trigger".
>It did work... I can't help but wonder if I missed some obvious
>and much simpler way to accomplish this!
You didn't miss it; this is a defect in ZPatterns which I discovered when
Ty began building a production app similar to yours in what it uses in
ZPatterns. As with many things in ZPatterns, it's not so much that it's
inherently complicated as it is unfinished, undocumented, and untested.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.
Re: [Zope-dev] More comments on ZPatterns
At 10:02 AM 7/10/00 -0400, Shane Hathaway wrote: >Phillip, > >What if the management interface for specialists provided a way to >manipulate, or at least view, the table of virtual objects (or, in >ZPatterns-speak, DataSkins)? Wouldn't that make ZPatterns more >accessible? Probably. The sticking points are twofold, however. 1) I'm not sure what a default for such an interface would look like, and so am holding off until Ty and I have built a couple of ones for "real life" use. 2) I need a good way to make the methods overrideable without any subclassing (whether in Python or ZClasses), since Specialists "want to be singletons". I have an idea about how to make Specialist and similar ObjectManagers able to permit adding of attributes that they already have, so long as it's a *class* attribute and not a manage_* method, but I haven't had time to implement it yet. If ObjectManagers did this themselves (wink wink, nudge nudge) it would lift a lot of restrictions I'm currently holding to with regard to default interfaces on Specialists, Racks, UserSources, etc., because then users could override them at a whim. I think this may relate to an existing interest of yours regarding specification of interfaces and overriding them in instances; I'd be interested in hearing your comments regardless. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
"Phillip J. Eby" wrote: > > At 10:02 AM 7/10/00 -0400, Shane Hathaway wrote: > >Phillip, > > > >What if the management interface for specialists provided a way to > >manipulate, or at least view, the table of virtual objects (or, in > >ZPatterns-speak, DataSkins)? Wouldn't that make ZPatterns more > >accessible? > > Probably. The sticking points are twofold, however. 1) I'm not sure what > a default for such an interface would look like, and so am holding off > until Ty and I have built a couple of ones for "real life" use. 2) I need > a good way to make the methods overrideable without any subclassing > (whether in Python or ZClasses), since Specialists "want to be singletons". > I have an idea about how to make Specialist and similar ObjectManagers > able to permit adding of attributes that they already have, so long as it's > a *class* attribute and not a manage_* method, but I haven't had time to > implement it yet. If ObjectManagers did this themselves (wink wink, nudge > nudge) it would lift a lot of restrictions I'm currently holding to with > regard to default interfaces on Specialists, Racks, UserSources, etc., > because then users could override them at a whim. I decided to try out this idea. It turned out to be a cinch! It doesn't restrict the manage_* methods yet; I'll get to that after I get some feedback. Thoroughly untested except on my box; use at your own risk, etc. :-) http://www.zope.org/Members/hathawsh/ConfigurableInstances/ > I think this may relate to an existing interest of yours regarding > specification of interfaces and overriding them in instances; I'd be > interested in hearing your comments regardless. The thing that's really missing is the interface that DatabaseConnector provides. It shows you all the methods you need to implement, and when you're done, the interface is ready to try out. This leads to a sense of completion, which in turn makes the user pleased to be using Zope/ZClasses/ZPatterns/etc. This can only be good. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
At 02:29 PM 7/10/00 -0400, Shane Hathaway wrote:
>
>I decided to try out this idea. It turned out to be a cinch! It
>doesn't restrict the manage_* methods yet; I'll get to that after I get
>some feedback. Thoroughly untested except on my box; use at your own
>risk, etc. :-)
>
>http://www.zope.org/Members/hathawsh/ConfigurableInstances/
>
Looks pretty good. A suggestion, however. There isn't any need to do it
as a patch to ObjectManager.py; you can implement this in a Product just
fine. Just organize it like this:
class ConfigurablesSheet:
...
class Configurable(OFS.ObjectManager.ObjectManager):
def _checkId(self, id, allow_dup=0):
...
class ConfigurablesSheets:
configurables = ConfigurablesSheet('configurables')
class _ZClass_for_Configurable:
propertysheets = ConfigurablesSheets()
_zclass_ = Configurable
manage_options=({'label': 'Configurable objects', 'action' :
'propertysheets/configurables/manage'},)
Then all you have to do is
context.registerZClass(_ZClass_for_Configurable), and anyone mixing in
Configurable to their bases will now have the configurable stuff on your
screen. (Btw, please don't take offense if you already knew how to do all
this; doing mixins to alter the ZClass machinery itself is pretty deep Zen
to most people, including me until just last week. I knew the theory
before that, but only actually did some mixins like this late last week,
working on some experimental stuff for PlugIns.)
>> I think this may relate to an existing interest of yours regarding
>> specification of interfaces and overriding them in instances; I'd be
>> interested in hearing your comments regardless.
>
>The thing that's really missing is the interface that DatabaseConnector
>provides. It shows you all the methods you need to implement, and when
>you're done, the interface is ready to try out. This leads to a sense
>of completion, which in turn makes the user pleased to be using
>Zope/ZClasses/ZPatterns/etc. This can only be good.
Yep, it would be nice to have such a thing. It's rather like PlugIns,
except it's designed for single methods, rather than lists of collaborator
objects. The other comment I have, now that I've seen your approach, is
that it might be more flexible from a subclassing perspective, to use a
__replaceable__ attribute. Here's how it could work:
1) Configurable._checkId() checks to see if the existing attribute to be
replaced has a __replaceable__ = true attribute, or if it lacks a
__replaceable__ attribute, it checks the objectmanager itself for a
subobjectname__replaceable__ attribute.
2) The Configurables ZClass mixin UI would set/reset
subobject.__replaceable__ on the list of names given (and in the case of
attribute errors would set/reset class.subobjectname__replaceable__
The advantage to this approach is that if you create mixin classes that are
designed to be added to Configurables, you don't have to go and re-check
your configurability list; the replacability lives with the methods, not
the class.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
"Phillip J. Eby" wrote: > >http://www.zope.org/Members/hathawsh/ConfigurableInstances/ > > Looks pretty good. A suggestion, however. There isn't any need to do it > as a patch to ObjectManager.py; you can implement this in a Product just > fine. Just organize it like this: (...) Thanks for the suggestion, but my intention was to try it out in the core Zope, not a product. It seems reasonable that all ObjectManager derivatives should have this capability, and that anything that isn't derived from ObjectManager doesn't need it. > Then all you have to do is > context.registerZClass(_ZClass_for_Configurable), and anyone mixing in > Configurable to their bases will now have the configurable stuff on your > screen. (Btw, please don't take offense if you already knew how to do all > this; doing mixins to alter the ZClass machinery itself is pretty deep Zen > to most people, including me until just last week. I knew the theory > before that, but only actually did some mixins like this late last week, > working on some experimental stuff for PlugIns.) I'm finding that everything seems like deep Zen until you learn it. (ZPatterns comes to mind. :-) )Using ZClass property sheets, I bet it won't be too difficult to get the plugins framework working with ZClasses. > >> I think this may relate to an existing interest of yours regarding > >> specification of interfaces and overriding them in instances; I'd be > >> interested in hearing your comments regardless. > > > >The thing that's really missing is the interface that DatabaseConnector > >provides. It shows you all the methods you need to implement, and when > >you're done, the interface is ready to try out. This leads to a sense > >of completion, which in turn makes the user pleased to be using > >Zope/ZClasses/ZPatterns/etc. This can only be good. > > Yep, it would be nice to have such a thing. It's rather like PlugIns, > except it's designed for single methods, rather than lists of collaborator > objects. The other comment I have, now that I've seen your approach, is > that it might be more flexible from a subclassing perspective, to use a > __replaceable__ attribute. Here's how it could work: > > 1) Configurable._checkId() checks to see if the existing attribute to be > replaced has a __replaceable__ = true attribute, or if it lacks a > __replaceable__ attribute, it checks the objectmanager itself for a > subobjectname__replaceable__ attribute. > > 2) The Configurables ZClass mixin UI would set/reset > subobject.__replaceable__ on the list of names given (and in the case of > attribute errors would set/reset class.subobjectname__replaceable__ > > The advantage to this approach is that if you create mixin classes that are > designed to be added to Configurables, you don't have to go and re-check > your configurability list; the replacability lives with the methods, not > the class. That's a great idea. It does indeed add flexibility. I'll try it. (soon. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
"Phillip J. Eby" wrote: > 2) I need > a good way to make the methods overrideable without any subclassing > (whether in Python or ZClasses), Ah, so it's not just me who wants this ;-) > I think this may relate to an existing interest of yours regarding > specification of interfaces and overriding them in instances; I'd be > interested in hearing your comments regardless. My interest too, don't know how to make it happen though :( cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More comments on ZPatterns
"Phillip J. Eby" wrote: > The other comment I have, now that I've seen your approach, is > that it might be more flexible from a subclassing perspective, to use a > __replaceable__ attribute. Here's how it could work: > > 1) Configurable._checkId() checks to see if the existing attribute to be > replaced has a __replaceable__ = true attribute, or if it lacks a > __replaceable__ attribute, it checks the objectmanager itself for a > subobjectname__replaceable__ attribute. > > 2) The Configurables ZClass mixin UI would set/reset > subobject.__replaceable__ on the list of names given (and in the case of > attribute errors would set/reset class.subobjectname__replaceable__ > > The advantage to this approach is that if you create mixin classes that are > designed to be added to Configurables, you don't have to go and re-check > your configurability list; the replacability lives with the methods, not > the class. Don't quite all fo this but it sounds like exactly what I'm after :-) I'll third it long after the thread is closed too in the hope that Shane can get this into the Zope core... Would a collector entry help? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
