[Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

[Jim Fulton]

Gary Poster wrote:
> 
> On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:
> 
>> Gary Poster wrote:
>> ...
>>
>>> 4 Recognize and document that the 'default' field argument is   
>>> actually 'initial value'.  That is, if you set a field with a  
>>> default  to the missing_value, the default does not become the  
>>> field's value:  the 'default' value is only used if the value has  
>>> never been set  (i.e., during creation or when there is no  previous 
>>> state of the  value).  Possibly rename to  'initial_value' (with 
>>> deprecation  support).  *would need proposal*
>>> 5 Allow fields to accept a default (or initial_value, as above)  
>>> *or*  a default_getter (or initial_value_getter, as above).   
>>> default_getter/ initial_value_getter would be a callable passed  the 
>>> field's context.   It should return the desired initial  value.  Use 
>>> cases include  initializing to now, today, the current  user, etc.  
>>> *would need small  proposal* *code exists*
>>>
>>
>> I'm uncomfortable with this. Right now, I think fields do too much.
>> They have too much application logic.  This would add more.  The whole
>> concept of "initial value" seems to be very application dependent.
>> Maybe it would be best to just drop the default field altogether
>> and introduce adapters for computing initial values in those special
>> cases when we need them.
> 
> 
> Initial value is a concept in XMLSchema (http://www.w3.org/TR/ 
> xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty sure  
> they are talking about what we are talking about.  I think it does  
> belong in a statement about a logical schema.

I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)

Here's what we say about default in the schema package's README.txt:

   "Default field values are assigned to objects when they are
    first created."

This is a statement either:

- about the past history of an object, or

- about some tool used to create an object.

I don't really see that this is of value in a schema.  A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past.  There's no way to
evaluate, for example, whether an object satisfies this aspect of
it's schema.

Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms.  We then create the object with whatever data
we get from an add form.  IOW, we don't really use it is an initial
value to create the object.

I suggest that the default should become a field in a formlib form-field
definition, and should be deprecated from schema field.

> Moreover, I regard any lookup code as an intellectual cost for  
> developers: a cost both for making and for finding the associated  
> configuration.  For schemas, being able to look in one place is very  
> valuable, at least to me.  APIDoc can help, but is not a panacea.  I  
> don't think this particular configuration division would be a win.

Agreed, but I think we are mixing concerns. Default is not a property
of the specification, but of a form definition.

> I think dropping the functionality of default would be a loss for  
> reasonable schema functionality.  I think renaming it to initial or  
> initial_value would be a win for accurate names.  I'm willing to drop  
> the getter: it is kind of ugly, I admit.
> 
> You ok with just changing the name?

I'd really prefer to move it to form field, and change the name.

>> ...
>>
>>
>>> 7 add combination field and widget to schema and form,  
>>> respectively.   A combination field allows a user to fill in  
>>> multiple values  simultaneously, and returns a tuple of the  combined 
>>> values.  Use  cases overlap somewhat with object field/ widget, but 
>>> this is simpler  to use for simple use cases.  Use  cases include 
>>> range fields.  *would  need small proposal* *code  exists*
>>
>>
>> I have an open mind, but I'm a bit skeptical (as you know :).  I  expect
>> this proposal to be a bit controversal.  Perhaps we can plan to go  
>> another
>> round of brainstorming during the sprint.
> 
> 
> OK--I must admit that I have a bit of the "hack" willies about it  too.  
> :-)  It's useful, though, and I haven't been convinced by any  
> alternatives yet.  This one's off the table for the sprint then,  except 
> perhaps for discussion.
> 
> For the record, here are the use cases that the Combination field  fills 
> now:
> 
> - range
> - main value plus modifier(s): find something supervised by X (a  
> person), directly or indirectly (a Bool); and select something for  
> publication (an object), in a given context (local, global, whatever).
> 
> I know you don't like the first one, and I do ATM :-).  The second  one 
> makes me more suspicious, though.  A combination field can  fulfill it, 
> but we have had a real use case, or at least desire, for  a list widget 
> of this sort of data structure.  Without a concept of  "main value" and 
> "secondary values" (and a combination widget doesn't  promise anything 
> like that) you can't get what we wanted.

Let's discuss this at the sprint.  I'll note that another option
is to push this to the form level.  For example, I would have a lot
less heartburn with combo form fields.  In any case, I don't have enough
heartburn to veto this idea.

Jim

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