Am 09.05.2010, 21:23 Uhr, schrieb Chris McDonough <chr...@plope.com>:
> 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
>> this definition misleading but possibly only because it is too brief. I
>> think form controls were the representation of the fields by the
>> 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
>> 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
>> provide some more useful feedback with a test application this week as
>> this suits my needs for my planned port of begeistert.org to BFG.
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
Clark Consulting & Research
Repoze-dev mailing list