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

Thu Oct 16 07:08:46 EDT 2008

Hi garz

Sorry I don't have to much time for answer all your questions
very well but let me give some hints.

> Betreff: Re: [Zope3-Users] thoughts about z3c.form-package
> 
> 
> 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.

I think that' an important point which you think we could skip.
If you are thinking that this fields could be obsolate then
let me explain what fields can do.

fields can be used at class level. This means you can define 
fields in a class and start to set values for the widgets
which they later will use. That's an important thing, if this
fields whould not exist, you whould have to use the widgets
directly in the python class an manipulate them there.
And also the widget whould be inherited from a kind of manager
which allows you to join different wiedget like we do with fields.

You are suggesting that the widget fields are to much. I think
not because if you like to support a framework which can do
what the z3c.from package does you will end up in implementing
a super mega widget calls whcih does everything. Our (HTML) 
widget implementation does only a minimum which allows you to 
customize what you need. The field implementation manages everything
which is not relevant for most developers. The widget and it's 
HTML attributes are relevant for developers if you like to 
implement a JSON aware or other Ajax pattern aware widgets.
e.g. a widget which knows hot to validata via Ajax etc.

In other words the field implementation which the widget adapts
handles all the internals, hiddees this part and offers an 
API in a clean way if you really need it. This is an abstraction.

Al what I like to say is, you probably can develope an other
formframework with a different kind of assempbling the different
parts in z3c.form. But I'm pretty sure that you will not be able
to do it with lesser methods then we did. Of corse you can 
put everything in a lesser components and skip the fields
implementation. But is this simpler?

> 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?

See my next comment. Fields are a fundamental part of 
our concept and are the component which allows you to define
things at python class level. (not in instance methods)
This makes it very simple to work with. or not?

> 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. :))

Why use another request? You can do whatever you need to
if you write python form classes. We often do something like:

fields = fieldFields(interface.IFoo)
fields['bar'].widgetFactory = getMySomethingWidget

Then the field (which is general) uses another widget.

That's all you need for apply another widget. Probably this 
makes a little bit simpler to understand what a field and 
what a widget does.

> best regards, gards ;)
> --
> View this message in context: 
> http://www.nabble.com/thoughts-about-z3c.form-package-tp198692
> 92p20000780.html
> Sent from the Zope3 - users mailing list archive at Nabble.com.
> 
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
> 