[Zope3-Users] thoughts about z3c.form-package

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

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.