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

[garz]

hey roger,

thank you for your answers. really appreciated. :)

@hook: i understand now, the applyChanges-method isnt a hook, its just a
function so that the apply-thing can be used alone too. a hook is, as far as
i understood this concept, a point of extensibility or variation. both isnt
possible in this case.

are their any different widget-implementations anywhere? i try to visualize
that the form is rendered to different content with different widgets. i'm
lacking use cases. =) i try to understand, why those fields are an
abstraction of the widget or why this abstraction is needed. i have the
feeling that there are only browser-widgets and when i have a look at the
action, which is implemented in the z3c.form core-package (means not in
browser), it already is a browser-widget (SubmitWidget), which means that
the abstraction there doesnt exist anymore.

if fields are the abstraction of widgets, ...
- why should it be possible to use widgets without fields?
- widgets shouldnt even be "known" to the user of z3c.form.

what i'm trying to do with these questions is to find out the concepts
behind z3c.form. i'm not used to functional programming style, its hard for
me to get into the idea. thats why i'm trying to reimplement an
object-oriented version with clear concepts that can be seen by the
definition and arrangement of the classes. plus i think those are at least a
little unobvious in z3c.form, that should be the reason why it is so hard to
understand and "complex", since it in fact isnt, when understood once.

but my problem is, i'm lacking experience in this kind of web-developement.
i dont know about all possibilities that can be done with zope. thats why
i'm asking you who has experience. :) you designed the package for a certain
purpose and i try to reengineer this purpose so that my version doesnt miss
any features. i hope that i'm not annoying you. :D just beeing curious.

i'm thinking about two possibilities conceptualizing fields for my version.
since i want to do it object-oriented, a field cant be only a collection of
values of something (functional style). a field should have a responsibility
for something. it is therefor able to encapsulate a concept -> concepts
become obvious through the classes.

1.) a field is the abstraction of a widget. now there are two possibilites
again:
     1.1) widgets can be used stand-alone
     1.2) widgets cant be used stand-alone

as i wrote, if widgets are the abstraction of a field, then users shouldnt
even get in contact with widgets. they should be a hidden concept. but since
i dont want to loose possibilities regarding z3c.form, it has to be possible
to use widgets stand-alone. but this results in forms that consist
specialized widgets (for example browser-widgets) and general fields. such a
form isnt general anymore. to keep concepts clean, widgets shouldnt be used
stand-alone.

2.) a field is only a manager associating a widget with an attribute of a
context
if abstracted widgets arent needed, this would mean, that widgets can be
used stand-alone.

and this is the reason i asked those questions at the beginning. i'm
thinking about if fields are an abstraction for the widgets...
a) ... in z3c.form
b) ... in general

a): as i wrote, in z3c.form the actions are in fact already one kind of
widget, namely the browser-widget SubmitWidget. at least here the concept of
fields abstracting widgets is broken.
b): maybe the field-concept isnt needed or overkill? as i sad, i'm lacking
use cases. i try to visualize: one time a form is rendered to html, the
other time the form is rendered to? which kind of request exists that
renders the form to something else?

ok, there is the pdf-example. with the field-concept, the fields should be
rendered to pdf-code (in this case just html) and the render method then
calls a different pagetemplate and embeds those widgets. since a call for
rendering pdf-content isnt distinguishable from a call for rendering
html-conent, the render-method has to be overwritten -> a new form emerges
that is specialized creating pdf-output -> no field-abstraction needed,
because this form will alway be for pdf-output.

the aim of a general form with general fields should be, that if it is once
defined, it can render itself to whatever output the request demands. in the
pdf-example this would mean, that the form can render pdf-output just
because of the request and if there was a different implementation using
different widgets that render to something else than the browserwidgets, the
field-abstraction would make perfectly sense. i'm trying to find out if this
use case really exists.

i hope you have the patience to enlighten me. :))

best regards, gards ;)
-- 
View this message in context: http://www.nabble.com/thoughts-about-z3c.form-package-tp19869292p20000780.html
Sent from the Zope3 - users mailing list archive at Nabble.com.