[Zope3-dev] Re: Schema, widget and form refactoring

[Fred L. Drake, Jr.]

I wrote:
 > This assumption is made many places, and might be tolerable, but I'm
 > not convinced.  Much of the form management support feels very weak.

Jim Fulton writes:
 > That non-specific statement feels ver weak. ;)

It was, and deliberatly:  I *really* don't want to end up bogged down
in this again.  It's also been a couple of months since I was that
deep in this part of things, and the details are (thankfully!) getting
fuzzy.

 > 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.

Definately!

 > > 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.

Probably so.  Gary and I didn't at the time since the names were
almost the only things that appeared to be the table; we elected to
cut our loses.

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

But getData() doesn't correspond to getInput().  getData() should be
able to use getInput() to perform part of it's work, though.
getInput() should only be used when haveData() (or haveInput()) is
true.

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

We agreed that the widget can supply the marker; we disagreed that the
widget *should* supply the marker.  In the common case, a single
marker for the entire form is sufficient, and would be a better
solution if *any* field required the marker.

 > >     (since empty string fields can be dropped as a misguided
 > >     "optimization" by the browser).
 > 
 > Really? I've never heard of that. Are you sure?

I didn't make it up; I'll see what I can find out.

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

Yes.

 > > 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.

The usage dance for the widget interface is definately very
complicated when compared with the interface documentation.  I think
the dance needs to be explained much more clearly, as it's critical to
understand it in detail when writing new widgets.

The descriptions I gave made no assumption about what circumstances
each method is called under.

 > > 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.

Wouldn't hurt who?

 > 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.

It should be.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation