Re: [Zope] Editing ZClasses - Hole in Documentation
Casey: As always, Thanks for your reply. I did actually find out about the manage_editProperties way to change things. However, what is left unsaid (and was really the purpose of my message) was that the way to set up the edit functionality in a ZClass is lacking. How can I have an extra method in a ZClass that sets up the edit screen and then tells a particular function to perform the edit? What I see now is that I have to have a separate DTML method (for the edit form) and a separate python script or DTML Method to actually modify the properties. What would be really nice would be to have the ZClass wizard set up an "editForm/edit" set of objects, just as it does the "addForm/add" objects. If you don't want the user to edit anything, simply restrict their access from the editForm object. That would make ZClasses much more attractive to site developers that just want to have a few extra properties of say, a DTML Document, but don't want to go through the hassle of making a python product. The way the system works now is that ZClasses are relatively easy to make and a real bear to edit (from the developer side). This makes ZClasses intitially attractive (because they are easy to make) but largely unwieldy in real life if your application needs to edit parameters in classes (which happens all the time). I will look into the book. Thanks for the plug. Best wishes (to all), Ron
On Thursday 15 November 2001 06:55 am, Ronald L. Chichester allegedly wrote: [snip]
Some of us have products we would like to roll out that require that users (including managers, owners, and yes, sometimes even anonymous (if your organization can handle that)) to edit the ZClass instance once it has been instantiated. I'm still hunting for either documentation or an example that has this capability. In a few instances, I have seen people say it is "trivial." It may be, once you find out how. Unfortunately, there is still some smoke and mirrors here. The solution isn't obvious to the casual developer.
If someone can prove me wrong, I would be thrilled to know about it.
Best,
Ron
You dare to suggest that there is a capability of Zope that is undocumented? I find the mere suggestion of this utterly infathomable!
Seriously, tho, the API of Zope and especially ZClasses is pretty opaque in places, unless you like hunting through the source code, which in the case of ZClasses doesn't help much without Jim F. looking over your shoulder... 8^)
Actually there is an example of how to do this right under your nose. The default constructor method of the ZClass has the important call syntax in a comment as an example. Something like:
<dtml-call expr="propertysheets.Basic.manage_editProperties(REQUEST)">
Now, manage_editProperties is fine so long as you want to change all of the properties at once, but not if you only need to change one or two. For that, use manage_changeProperties.
This call would work in response to a form (either from Python or DTML):
propertysheets.my_property_sheet.manage_changeProperties(REQUEST)
just make sure the ZClass instance is at the top of the namespace stack, which is easily accomplished using the URL as in:
http://zope/path/to/instance/editMethod
<plug type="shameless"> You can find a complete example of a ZClass based app in the newly-published "Book of Zope" which is sadly only available in dead-tree form. Although you can download the ZCatalog chapter at www.nostarch.com. </plug>
hth, /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
On Thursday 15 November 2001 10:42 am, complaw@hal-pc.org allegedly wrote:
Casey:
As always, Thanks for your reply.
I did actually find out about the manage_editProperties way to change things. However, what is left unsaid (and was really the purpose of my message) was that the way to set up the edit functionality in a ZClass is lacking. How can I have an extra method in a ZClass that sets up the edit screen and then tells a particular function to perform the edit? What I see now is that I have to have a separate DTML method (for the edit form) and a separate python script or DTML Method to actually modify the properties.
Right. I definitely think there is a gap in the docs between the API and actually creating a working system. Us "old dogs" probably either a. Eschew ZClasses entirely. (I still find them handy for quick and dirty objects that are little more than glorified DTML documents or data records) b. Know how to do it and find writing about it too difficult, time consuming or not worth their time, or think it is "obvious" forgetting about the time we spent banging our collective heads against the same wall.
What would be really nice would be to have the ZClass wizard set up an "editForm/edit" set of objects, just as it does the "addForm/add" objects. If you don't want the user to edit anything, simply restrict their access from the editForm object. That would make ZClasses much more attractive to site developers that just want to have a few extra properties of say, a DTML Document, but don't want to go through the hassle of making a python product.
That is a great idea. I guess some sort of construction system would need to be built so that you could create a property sheet and then have it build a user interface for it, which would create DTML/python scripts in the ZClass for you. I think the current constructor methods need work anyway. They are really very minimal as it is. The problem I think we all run up against is that ZClasses have limitations and drawbacks beyond this. So anytime I think about making interface improvements, I think about whether I really want to encourage people to use ZClasses that much in their current form. And then it all turns into a big huge rethink about the whole thing and I give up and work on something else instead...
The way the system works now is that ZClasses are relatively easy to make and a real bear to edit (from the developer side). This makes ZClasses intitially attractive (because they are easy to make) but largely unwieldy in real life if your application needs to edit parameters in classes (which happens all the time).
ZClasses are the low-hanging fruit. Unfortunately there are currently a lot of thorns hidden in there IMHO.
I will look into the book. Thanks for the plug.
Best wishes (to all),
Ron
/---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
Hi Casey, I encountered the same problem starting with Zope. ZClasses seem the obvious vehicel for encapsulating reusable functionality, but there are so many possibilities of doing things that it is rather unclear to me what would be the best way to do things. Maybe there is a need for some kind of best practices document. When I started with ZClasses, I stored all my properties in Property sheets, which is good because the property sheets are inherited by the instances of the class, so adding a new property to the class, automatically adds it to your instance, but I found it very akward to work with. The code that handles form posts and retrieval of values had to know about them. Currently I have one DTML-form for every z-class defining all *properties* of this class. This DTML-form is used for the new operation and the edit operation. I created a little python script called widget, which is passed the name and type of field and looks up the value of this property in the context and request. Another python method handles the post and creates a new object or edits it. This works for me and allows me to create editable objects by defining the main edit document. I would be very interested to know how other people handle this specific problem. Douwe
Hi, I want to create a Z Class that communicates with a database. I first created the Z Class, created an instance of it and put all my Connection and SQL Methods in the _instance_, figuring I put them in the Z Class when I got everything to work. I works now, but if I put everything in the Z Class, Zope complains that access to my SQL methods is no unauthorized. Recreating the method in the Z Class and copying the code doesn't help. Any ideas? Douwe
Douwe Osinga writes:
I want to create a Z Class that communicates with a database. I first created the Z Class, created an instance of it and put all my Connection and SQL Methods in the _instance_, figuring I put them in the Z Class when I got everything to work. I works now, but if I put everything in the Z Class, Zope complains that access to my SQL methods is no unauthorized. Recreating the method in the Z Class and copying the code doesn't help. Did you adjust the "Permission Mapping" for "Use Database Methods"?
It is mapped to "disabled" by default... Dieter
participants (4)
-
Casey Duncan -
complaw＠hal-pc.org -
Dieter Maurer -
Douwe Osinga