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. _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users