On Mon, 2010-05-10 at 12:55 +0200, Charlie Clark wrote:
> 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.

That's a good idea.  But I'm going to categorize swappability as "not
worth it" right now, as then the meta-features might start to overshadow
the non-meta features, as is the case in a lot of Zope software.  It's
also a lot of work to make it actually pluggable, but not so much work
to make the interactions small so that people can fork it as necessary
if they don't like one of the components.

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


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

I'm going to leave it as-is for now but if you feel like making direct
changes to the docs along these lines, I wouldn't complain much.

> >>  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 begeistert.org to BFG.
> 
> > Cool.
> 
> Well, hardly a headline website but one that I've not yet found a really  
> adequate blueprint for.
> 
> Regarding the demos:
> 
> http://deformdemo.repoze.org/
> 
> 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  
> year).

Yes, obviously more and more complex widgets are necessary.  The
TODO.txt in the package outlines some of the more desirable ones.

- C


_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to