Am 09.05.2010, 21:23 Uhr, schrieb Chris McDonough <>:

> Yes.  I should just remove the definitions in the glossary because they
> are actually defined better in the chapter I linked to.

Looking much better now. In the Say What? section would it be sensible to  
trumpet the idea of interfaces/specification which allows Colander and  
Peppercorn to work together and presumably allows either of them to be  
replaced if required? Just to say they are unrelated is incorrect as they  
are related by domain but not interdependent.

>> Looking at the "data trip" I am vaguely reminded of mathematical
>> transformations and wonder if that metaphor might not be useful in this
>> context - putting the various representations/structures in the CAST
>> quadrants. OTOH I never really understood it back then!
>> Would we have 4 quadrants? Storage, Application, Network and Browser?
> No idea, I about flunked math.

I think I should have done as well but we spent more than half of our time  
doing past papers so even the monkeys in my class had a fair chance of  
passing! The improved definitions make this less relevant but essentially  
we have transitions or changes of state where the fields themselves are  
transformed/adapted as required. This makes Colander and Peppercorn state  

FWIW from memory CAST related to signedness in trig functions:

C | A
S | T

Anything similar would lend itself to a graphical reminder of the relevant  

>> And finally "form controls" refers to "A sequence of form fields". I  
>> find
>> this definition misleading but possibly only because it is too brief. I
>> think form controls were the representation of the fields by the  
>> browser,
>> but that this definition comes from GUI-programming as isn't directly
>> relevant here.

> The distinction I'm trying to make is the raw data given to us as the
> result of a form submission (currently "controls" vs. the data that
> peppercorn returns (pstruct)).

See above - the fields change state but stay fields. This is a very fiddly  
area and something I'm still not 100% on despite Philip von W's extensive  
coverage of zope.formlib in his excellent book.

>>  But that wouldn't fit in the sentence "Deform passes a set
>> of form controls to the parse method". Why doesn't it just pass the set  
>> of
>> form fields?
> Because we use the word "field" elsewhere.  I was trying to not overlap
> the vocabulary.  I probably failed in places.

>> Sorry, if this is all to picky at the level of the language. I'll try  
>> and
>> provide some more useful feedback with a test application this week as
>> this suits my needs for my planned port of to BFG.

> Cool.

Well, hardly a headline website but one that I've not yet found a really  
adequate blueprint for.

Regarding the demos:

It might be an idea to extend them for more adventurous use cases as in  
z3c.form which has an address book and even a spreadsheet. I'd personally  
also like to see how images would be handled with previews in edit forms  
and not having them wiped if nothing new is uploaded. From the doc it  
looks like the support for this reasonably common use case (and something  
that requires hacking in zope.formlib) is in deform. This is something I'd  
like to work on in any sprint.

I'd prefer dates not to be in parts as <input type="date"> is in HTML and  
already nicely supported by Opera. More importantly a single text field is  
also used by the various JS equivalents. Not sure, however, if there is an  
easy way to detect this but the parts solution could be offered as an  
alternative widget (using select for day and month and datalist for the  

Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Repoze-dev mailing list

Reply via email to