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).

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: <dtml-unless sequence-end>,</dtml-unless> 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.

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.

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.

"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