[Zope-dev] ZFormulator review...

[Martijn Faassen]

Chris McDonough wrote:

[snip summary of what ZFormulator indeed does]
> - Martijn includes a .zexp file for demo purposes in the product which
> gets placed into the import directory upon untarring the product file.

Yes, with XMLWidgets I had the .zexp separated out (one for demos and
one for necessary ZClasses). Then I noticed some other products had the
.zexp included and I like that better, as it's far less of a hassle to
download and install. The components are heavily dependent on each other
anyway; it's often unlikely for instance that a 0.1 demo runs with a 0.2
product.

> I think this is OK, but I wonder if anybody else has thoughts on the
> implications of placing stuff into directories other than the intended
> product directory within a product tarball?  For instance, I would
> consider it bad form for a Product to expand something into the
> lib/python/OFS directory. 

Me too, if it didn't give appropriate warning.

> Others might disagree.  What about products
> just going right ahead and creating instances of their classes within
> the ZODB upon installation? 

Can this actually be done?

> Or products automatically importing demo
> .zexp (or equivalent) files into the App object?  Bad form or no?

I think some installation framework could be created that allows things
like this, but then the installation framework would need to explicitly
state what is happening at each time. If you work with tarballs, the
download page should state clearly that something tricky will happen,
whenever something tricky happens.

The import and extensions directories are okay in this way to me though,
except that you could run into namespace problems. Some filenames could
already be in use.
 
> - The owner and group of all Martij's product files are
> martijn/martijn.

faassen/faassen, I'd think. :)

[snip discussion of tar behavior, which has some good posts in this
thread]

> - ZFormulator is a good example of how to create a folderish object
> within a Python product that constrains addable meta-types to certain
> other object types.

Well, not too good as it's still buggy!

> In Martijn's product, he creates a base class named
> Form that inherits from ObjectManager, RoleManager, and SimpleItem.
> Since the Form base class inherits from ObjectManager, it is folderish.
> He overrides ObjectManager's all_meta_types method, and though I can't
> quite follow the logic as to how he populates the meta_types list within
> the class, it works, constraining the addable meta_types to those he
> chooses in a registration function (in this case, the individual field
> types, such as checkbox, textarea, etc.) 

The tricky part is that meta_types is officially a tuple. It can't be a
list, to my great regret. This means I need to do some tuple adding in
the register function, and then *manually* add change the *class* data
member. Since the class is not used to create new fields before
registration of fields happens, this works. It's not nice though. The
Form.py file is full of hacks, just to make the registration process
work cleanly.
 
And it contains bugs; somehow you can't add a field if you aren't a
superuser. I still would like to know what causes this. I'm completely
in the dark myself. May be something obvious, but I don't know where to
begin looking..

> I learned some tricks from
> this.  One of the unintuitive things about constraining addable objects
> this way is that  a ZFormulatorForm instance's Security tab still shows
> permission descriptions for aquired object types (such as Folders,
> etc).  Not a really big deal, but sure to confuse some people.

Would it be possible to actually get rid of the superfluous permission
descriptions? I don't see currently how a product could tell Zope about
this.. Couldn't/Shouldn't Zope check the meta_types itself for this?
 
> - The UI of ZFormulator is pretty standard, first you create a
> ZFormulatorForm object (this is an object that is represented by the
> Form class) by choosing it from the addable object dropdown.  

This works through semi-standard Zope object add code.

> Then you click on that object to start messing with it.
> While you're messing
> around with it, you can add BasicFields, TextboxFields, CheckboxFields,
> and a bunch of other form widgets inside the Form. Each object type has
> its own icon (nice!) and each object type corresponds to a different
> object class (e.g. the TextareaField class, the CheckboxField class,
> etc.)  You create the form widget object through the standard Zope
> management interface through the add dropdown.

Read: this works through horribly unstandard kludged up object add code.
I keep wishing someone will look at it and propose a simple solution!
And
there's my bug..

> After you've done that,
> you navigate to the form object by clicking on it and redefining its
> properties.  One thing that I'm sort of on the fence about is calling
> MessageDialog when properties for objects are changed.  Martijn does
> this for most all changes within the UI.  I sometimes find that this
> gets old after a while ("Yes, I know, thanks, I changed the object
> properties.")

Me too, but it was in the code I copied and when I tried to change it
into the way DTML methods are edited, it didn't work anymore. :) I
didn't dig into this, though.

> There isn't really much of a standard within Zope about
> calling MessageDialog (for example, SQL method Edit properties, when
> changed, don't call MessageDialog, they instead put a "last changed"
> blurb at the top of the management screen).  Any comments?

I generally like the 'last changed' blurb better. This is a typical area
for product GUI guidelines.

> Additionally, what if a person were to create a Wizard-style interface
> for the addition of forms and form elements.  Martijn has taken the
> approach of creating forms and form elements one-at-a-time via the Zope
> UI, but I could easily see a multipart form Wizard that would lead a
> user through the creation of a form and its elements without him or her
> knowing that he/she is instantiating things within the ZODB.  Thoughts?

I think you could make a separate wizard system that calls
ZFormulatorForm when necessary through some unspecified-as-yet API. I
think a wizard has rather a lot of limitations though, as you will make
mistakes and you'll want to adjust things later. So you'd go into the
ZFormulator interface again after all.

ZFormulator is not aimed at content managers primarily (though it may
help here) but at developers.

> -  Martijn defines something like 27 classes that live within his
> product.  Each of these classes, for the most part, is defined in a
> separate Python module within the product directory.  I don't mind this
> at all.  Anybody have anything to say about that?

ZFormulator defines a system which allows you to 'plug in' your own
field classes. That's why I put most of the classes in separate files.
 
> - I don't really want to get too deep into reviewing code here,

darn. :)

> so I'm
> just going to report errors and things that I think are a tiny bit askew
> (:-))... within a ZFormulator form, when adding a *second* instance of
> the same type of object (for example, a second TextareaField), I
> intermittently got an AttributeError, "None" object has no attributes
> coming from Field.py line 138 in _setSheet.

Hm. Perhaps this is a bug I already fixed, but I can't reproduce this
one right now.

> Martijn, I would also give
> a little blurb as to what "Order" means within the Form elements add and
> edit UI as its not immediately obvious (I figured it out by reading the
> code).  

All right. ZFormulator needs more documentation anyway. :)

> The View button between form elements produces inconsistent
> results (for example, a checkbox returns quoted HTML of the form
> element, while a textarea View shows the default value for the form
> element without any HTML)

The HTML *is* being spewed (look at the page source), but since it's
just a fragment so it's just randomly misinterpreted by the browser. The
entire
'view' feature is dubious with the 'test' tab already there anyway, so I
may
just remove it. Anyone have any opinions?
 
> Also, the ListField input box for the list
> elements should probably be split into separate key/value fields instead
> of using the pipe as a separator between key and value within a
> textarea.

Which leads to beautiful problems with two seperately scrollable
textarea widgets? :)

I'm interested in offering 'complex widgets' for ZFormulator eventually,
i.e. widgets consisting of more than a single HTML form element, with
extra buttons for some functionality, etc. Still thinking about this
one.

>  I know SQL integration is a "work in progress", and doesn't
> actually do much yet.  I'd almost be apt to leave it out of the product
> entirely as it's sort of hurts my brain to think about where my form
> values are coming from and going to in the context of using the product
> as a SQL conduit.

SQL integration does need some rethink. Some people have been thinking
about it more than I have recently, and eventually I hope to progress
some on this front. I'm not sure I understand your brain-hurt, though.
My brain-hurt is different and has to do with table synchronisation
issues (if you change the form, the SQL table structure can change, so
what now?).

> Also, when navigating with the back-forward buttons
> within a browser between forms created using ZFormulator (even within
> the ZFormulator UI which "eats its own dogfood"), browser errors
> indicating that form responses have expired are common.  I imagine this
> is a pretty tough one to avoid, and I haven't looked at the code closely
> enough to see why it happens with ZFormulator forms more often than with
> Zope HTMLFile-derived forms.

Hm, I don't know a thing about form responses expiring and such. I'll
need to think more about this one.

> Nice product Martijn!  Well done!

Thanks! Any clues on cleaning up Form.py and getting rid of my bug? :)

Regards,

Martijn