Am Mittwoch 08 Oktober 2008 01:11:24 schrieb garz:
> hey,
> while using z3c.form-package i reach its limits here and there. thats why i
> started to think about how a more general implemention should look like. my
> intention of writing this is that i want to know what you are thinking
> about it and i want to know the design-decisions that led to the different
> aspects of z3c.form.
> in the first part i try to give definitions of the concepts of z3c.form as
> would understand them.
> summary:
> z3c.form is all about this one use-case where the user describes a context
> with the help of a schema. you define fields, those fields are used to
> create fieldwidgets and those are rendered in the standard-forms from
> z3c.formui. its very nice to have this use-case well supported, but this
> support should be based on more general implementations. this would enable
> the user to create any kind of form.

Yes, that's the obvious use-case. However, there's much more you can do with 
z3c.form, I often use z3c.form for context-less patterns, or use a session as 
context. In my scenario here, I sparely use ZODB, instead, I have 
SQLAlchemy-based functions that I call in the button handlers. Thus I have 
already interfaces/schemas for all RDB objects, and what I do is to define 
interfaces for those forms and copy those schemas I need into this 
form-interface. Then I can use this interface in my form via 

But I have to admit, it took me quite a long time to implement certain 
patterns, and very often, the solution I tried was not possible due to some 
complicated z3c.form internals, meaning, I often tried to violate some 
concepts (as I did not understand them).

I think I'm not the only one here, I read quite often about similar problems 
in this list here, so this is my resumee:

- z3c.form is complex
- It's not obvious how to implement certain form-patterns
- People are often overwhelmed by that and don't look through

So, I think two solutions to that could be:

- Improve the documentation (however, I'm unsure in what way, though).
- Create a WIKI or something similar where people can find suggestions how to 
implement certain patterns with z3c.form.
- Do some "voting" machinery where people can choose which patterns they 
really use. This information may be valuable to find out what people expect  
from a form package and which concepts people actually understand and use.
- If we find patterns that can not be implemented with z3c.form in a viable 
way, try to extend z3c.form so that it is possible.

For me, this looks like the better approach than to trying to implement 
a "better" form package that may lead to the very same problems as z3c.form 
in the end.

Best Regards,

GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
Zope3-users mailing list

Reply via email to