[Zope] Editing ZClasses - Hole in Documentation

[Casey Duncan]

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
\---------------------------------------------------/