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

[Gary Poster]

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.

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.

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?

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

>> 10 The big restructuring of schema: divide up schema into  
>> interface  values and usage relationships.  This is too big to  
>> explain in this  email, and probably too big to even adequately  
>> begin in two days.   This is the direction Jim wants to take  
>> schema, though, and I'm +1.
>>
>
> See:
> http://mail.zope.org/pipermail/interface-dev/2004-June/000048.html

Cool, thanks.

Gary