[Zope3-dev] Schema, widget and form refactoring (was Re: [Zope3-checkins] CVS: Zope3/src/zope/schema - _bootstrapfields.py:1.19.2.1)

[Jim Fulton]

Fred L. Drake, Jr. wrote:
> This is a long message.  Sorry.  But I think it's worth reading for
> those playing with the nastiness that is the current forms machinery.
> 
> In a checkin message, Garrett Smith writes:

...

>  > - Modified the update logic for objects to skip fields that are not
>  >   present in the request form. Prior to this change, unspecified values
>  >   (i.e. values not in the request form) would cause default values to be
>  >   set for corresponding object fields.
> 
> Hmm.  I haven't read the code changes yet.  How are you determining
> what was sent to the browser?  Are you assuming that self-posting
> forms always have the same set of widgets?
> 
> This assumption is made many places, and might be tolerable, but I'm
> not convinced.  Much of the form management support feels very weak.

That non-specific statement feels ver weak. ;)


> It's true for the standard add/edit/schemadisplay forms, but may not
> be true for others; fields could easily be displayed conditionally,
> and so appear and disappear at "partial submit" events based on other
> state in the form.

I'm hoping that a clarification of the meaning of "required", "missing",
and "default" might help here.  I'm inclined to think though that if a
user hasn't provided input, then we shouldn't substitute a default or missing
value for an existing value.


>  > - Text fields have a missing_value of '' (empty string) instead of None.
> 
> Argh.  I know there is a popular position that this is the right thing
> to do, but it doesn't feel right to me.  Using None as the default
> missing_value makes it easier to detect careless bugs.

I agree. What is the motivation for making '' the default missing value?

...


> The biggest problem is that getData(), haveData(), and setData() sound
> like they're closely related, and they simply aren't. 

Yup. We also discussed renaming them.  I'm all for that. Maybe now's the
time.

 > Here's how we
> ended up describing them:
> 
> getData()
>     Return the converted value that's the result of the request.  Not
>     that setData() only affects this is haveData() is false; once the
>     field is part of the request, this should always come from the
>     form.

I don't remember what you suggested, but something like:

   getInput(()

might be better


> haveData() (hasData() in your branch)
>     Whether or not the field was present in the request that caused
>     the form to be generated.  For complex widgets,

And some very simple widgets, like checkboxes

 >     it's almost
>     impossible to get away without a marker to say "I'm here",
>     especially if a valid state is to have no other input from the
>     browser

Fortunately, it's easy enough for the widget to provide the marker. :)
(Fred and Gary don't agree with me on this point.)

 >     (since empty string fields can be dropped as a misguided
>     "optimization" by the browser).

Really? I've never heard of that. Are you sure?

This might be a good time to rename this to haveInput.

> setData()
>     Set the initial value of the widget for it's initial display.
>     When a form is re-rendered due to a "partial submit", this value
>     is ignored, and the value from the request is used instead.  This
>     requires *really* knowing what the value was on the browser when
>     the submit button was pressed---even if it was an empty string.

This isn't right. If this call is made, the value passed is displayed
even if there is user input.  the forms machinery only calls this if
there is no user input.



> You're changing the interpretation of haveData() in a fundamental
> way.  It may work for most of the standard widgets, but I'm very wary
> of this change.  (But like I said, I've not read the code yet.)

Right, I wonder what the motivation for this is.

> Now, I'm not ready to take up a jihad to fix what I think is wrong
> with the form machinery. 

It wouldn't hurt to raise some of the issues you have.



> But some clarity and improved documentation
> seems essential if we going to make this stuff easier to work with.

Especially for field and widget developers.

> The difficulty of understanding what's going on is an enormous entry
> barrier even for some very smart people.  Changing the
> get/have/setData() behavior needs very careful review.  The effects
> to code will spread well beyond the Zope 3 core, and not just in Zope
> Corporation projects.

Yup.

I think we have enough experience with this framework that we can identify some
problems.  I think it would be worthwhile discussing the issues and possible
solutions before we go much further.


Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org