Consolidating Multiple Property Sheets in ZClasses (plus CatalogAwareness)

Created by . Last modified on 2003/08/05.

I wish there were a builtin way to integrate builtin property sheets, both inherited and peer, because that would greatly simplify maintenance of ZClass management stuff. But there isn't, and here's the setup when you're making custom sheets":

(I'm not claiming this is the best design, but here goes...)

• You have a dtml method with the requisite HTML form for your properties in your product folder and in your ZClass. I don't think acquisition helps us here.
• You have several property sheets, either inherited or defined, that you want in a unified interface.
• You have a ZClass-made add method in your product folder (a constructor).
• You have an edit method in your ZClass.

In the add/edit form, the action for the Submit button should be the add or edit method, depending on where it is. The names of the form elements (HTML inputs) should be the names of the properties in your property sheets you want to add/change. When you submit this form, the method it is submitted to gets a REQUEST object with keys named for the form elements, each associated with the value in the element when the form was submitted. You can see these in the URL line when you submit with GET.

So it comes to the add method, which creates a new object in the dtml-with, then works in its namespace. While in the new object's namespace you can:

• set the properties of your property sheets. Call "propertysheets.PROPERTYSHEETNAME.manage_changeProperties(REQUEST)" for each property sheet. You are handing the REQUEST that your form gave you to this method, which will then change all the attributes in its property sheet that match keys in the REQUEST to the values that those keys correspond to. Read the ZClass source to see exactly how. The edit method is little less kind, and DC folks have said that it's not meant for public consumption.
• set it to be aware of a non-default Catalog: use dtml-call with manage_editCataloger to set it, and the call index to add it. (I think editCataloger should do this itself. Perhaps someone could tell me why I shouldn't patch it to index to a new catalog if the catalog actually changes.) This should be done after the properties are changed.

Typically you then redirect to whatever page should come after clicking submit. The ZClass constructor does this for you.

You will do the same thing in your edit method, except you will not make a new object, and you're already in the appropriate namespace. You can do this in a DTML method patterened after the ZClass constructor, but this is where PythonScripts are good. One might look something like:

# Keep in mind I'm making this up off the top of my head. I'll verify it against my code later...
context.propertysheets.PROPERTYSHEETNAME1.manage_changeProperties(REQUEST)
context.propertysheets.PROPERTYSHEETNAME2.manage_changeProperties(REQUEST)

return context.REQUEST.RESPONSE.redirect(location)

Easy huh?

So then you just go into the ZClass management interface and add your edit method to a tab, test it out, and you're done.

Issues:

• am I wrong? It seems to work for me.
• is there a more maintainable design? Dunno, I'd have to experiment.
• Perhaps Formulator would be well applied for this type of thing.