Am 09.05.2010, 16:16 Uhr, schrieb Chris McDonough <>:

>> just flipping through the documentation and things are looking good. I
>> like the fact that schemas avoid the confusion that Zope "interfaces as
>> schemas" can cause. Nevertheless, it can be convenient to be able to tie
>> them together.

> I'll definitely be working on a system at some point that generates
> forms from the definition of a "content type".  I don't know if those
> definitions will be done in terms of a Zope interface or not yet.  So at
> this point my attitude is "it can be convenient to generate forms from
> content", which may or may not turn out to be the same thing as "it can
> be convenient to generate forms from Zope interfaces".

To make myself clear on this - I agree that convenience is great. Anything  
that means that schema and interface definition do not have to be  
duplicated. However, the current elision of the difference that is  
possible in Zope is not a good thing.

>> As with all libraries of this kind the necessary abstraction requires  
>> some
>> new concepts or terminologies. I think I understand and like the
>> appstruct, cstruct and pstruct things (if not the names) but only  
>> working
>> with them will let me know. However, the definition of pstruct is either
>> incorrect or misleading:
>> "pstruct
>> Data deserialized by Peppercorn to a representation suitable for
>> consumption by a deform deserializer. Usually, when used in deform, a
>> cstruct is composed entirely of lists, dictionaries, strings, and file
>> objects."
>> I guess it should be "pstruct" in the second sentence.
> Yes.  Fixed, thanks.

This leads to the following definitions:

"Usually, when used in deform, a pstruct is composed entirely of lists,  
dictionaries, strings, and file objects."
"Usually, when used in deform, a cstruct is composed entirely of lists,  
dictionaries, strings, and file objects."

Clearly additional explanation is required otherwise pstruct and cstruct  
seem equivalent where they may only be analogous.

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?

Another area where I find the semantics getting in the way:

"For each schema node in the schema provided by the application developer,  
Deform creates a field. This happens recursively for each element in the  
schema. As a result, a tree of fields is created, mirroring the nodes in  
the schema."

Elements and nodes are interchangeable? If so I would suggest sticking  
with one term in general and using metaphors consistently: graphs have  
nodes, trees have leaves and compounds are made up of elements. So that "a  
tree of fields is created which mirrors the tree of elements in the  
schema" or some such as I'm not too happy with that either. I think the  
important thing is the ability to nest elements of the schema.

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

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.

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