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 field.Fields(IMyForm). 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, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users