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. 1.) what are the parts of a form-description? forms are composed of widgets, actions and other forms. these elements are rendered into the template and are therefor the forms elements. a form doesnt consist of anything else. 2.) what are fields? if one is using widgets, the task of assigning the extracted values of the widgets to an attribute of the context arises. if you dont want to do this by hand, you can use fields. they additionaly provide standard-values, constraints and validations. as those fields provide the validation, they always want to be used in combination with a widget. this stands in conflict with what fields are expect to be, the connection between attributes of a context and the widgets. for me it feels like they are doing a little too much. two concepts which should have been separated are unified in one object. now the button comes into play. the button is a field too. needs a button validation? is a button conntected to a form attribute? in my opinion, a button isnt a field at all. at least this is very confusing. i cant detect a clear concept behind a field. as i tried to show, the field as it is used now mixes at least 3 different concepts. so i'm asking, what is the definition of a field? from the z3c.form.field.txt: "The formlib uses form fields, to describe how the form should be put together." this isnt true, the fields describe, which attributes will be presented through which widget. the form itself consists of widgets. a field is only a little helper. 3.) managers (fields, fieldwidgets, buttons, actions) if you have a group of widgets, fields, buttons or actions that belong to one concern, you can use a manager to collect them. in templates you can iterate through widget-managers and display all of its widgets or let it extract all data at once. in z3c.form in contrast, all those little elements cant be used without their managers. the using of a single field requires the fields-manager because only it is consulted by the fieldwidgets-manager which in turn is the only one that knows how to create a fieldwidget. fields should be able to create their fieldwidgets on their own. managers shouldnt in fact don't really be needed. they only should be a nice addition if you want to group something of the same concern. so why was it done this way? 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. some general words about object orientation: z3c.form isnt object oriented in all parts. for example the field which connects context-attributes to widgets. it should be the fields responsibility to apply those values extracted from the widget to the attribute. instead it is done by an external method z3c.form.applyChanges that is called by EditForm. in this case i can imagine that this was done for performance reasons. but if you had want to save method-calls (calling an apply-method of every field), then the fields-manager should be the guy to do this task. instead the field-manager is iterated from the outside and the values are assigned from this external method. this is clearly functional programming with objects as datacontainers. this has several disadvantages: 1.) in my case i want to introduce a new field-type that is able to handle subforms (for the loved and hated objectwidget). applying a value to a subobject isnt the same as applying a value to a primitve attribute like an integer or string. the solution as it is implemented in z3c.form would be to rewrite the applyChanges-function to add an if-statement that devides between the different field-types. polymorphism was developed to handle those use-cases. 2.) the field is a connector to an attribute. only the field should know, which attribute it is connected to. by implementing it the way it was done in EditForm, it is assumed, that the name of the attribute of the context, the name the field and the name the widget uses are all the same. its not really an issue because that's the way it is, but this is not clean, because it could be different or something could be changed and then it would be different. some little things 1.) fieldwidget this should be a subclass of widget, instead a widget and a fieldwidget are the same and differences are if-ed. this is not a big issue as well, but it also isnt clean as well. 2.) prefixes prefixes could be generated by joining every name of every parent of an element. instead they are created by hand and assigned directly. should this result in a better performance too? otherwise its cumbersome, import util, expandPrefix... its not necessary. now i'm interested in your points of view. nobody should feel offended. its just that i'm coming to the conclusions i presented and that i now want to know, if they are wrong or right. for explanation: all these thoughts came from my plan to write a general list- and dictionary-form. for this i already started to write a new implementation of a form-package based z3c.form, but at some points i'm not sure if i'm right. thats why i want to discuss the basic thoughts of my approach. i feel that in the existing implementation a lot of stuff is optimized for speed, but sometimes i'm not sure about this, as i explained in the object orientation-part. there it feels to me like the principles of object orientation were not used. i'm not sure, give me explanation. :) and not only about this, about fields and the managers too. -- View this message in context: http://www.nabble.com/thoughts-about-z3c.form-package-tp19869292p19869292.html Sent from the Zope3 - users mailing list archive at Nabble.com. _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users