thx for your replies! now i have new stuff to think about. :)
Can you give an example what you can't do with z3c.form?
i think z3c.form is in respect of what can be done with it general enough. i
can realize what i want to do with it plus i know how to do it. it isnt that
i dont understand z3c.form, i even think i nearly fully understand it. the
issue is, that i cant do it in a nice way and i think if z3c.form would be
structured differently, this shouldnt be a problem... at least i think that.
but maybe this will change after thinking about what you guys wrote. then i
will probably be back with new stuff to discuss, when i try to realize my
list- and dict-forms further on. :)
I have some ideas how I think a subform should be implemented.
> THe existing implementation doesn't fit. It at least has some
> issues if you write complex forms with complex action and handlers.
> The update order of a form and subform is an important part
> which doesn't fit in the existing implementation.
since you mean by subform this:
A subform should be used to write forms with totaly different objects
> as context. A sub form can probably used for write a form for items
> in a container etc.
what are your imaginations about the problem that would arise? why should
the update-order should be an issue?
In general I see your point, z3c.form provides many, many hooks
> which looks like a little or big overhead.
this wasnt what i wanted to express. :D i dont think that there are too many
hooks, i like them and i think this is a really nice design with those
adapters. i have never seen this before and and know that i understand it i
can say that i learned a lot. =)
> Let's see what Adam Groszer is doing with the ObjectWidget
> implementation, probably this could be used for your use cases.
this objectwidget would really be nice. i already have a working
implementation with my own subform-package that you took a look at. and i
already tried to turn it into an objectwidget, but then i didnt like the way
it would have to be done in z3c.form and i started thinking about a better
form-package and this thread was born. :D
but now, as i said, i will have to think over everything again. then i'll be
until then i made a uml-graph, giving an overview over z3c.form-package. it
shows the classes, their methods and the hooks, conceptually. this means i
added the (from my point of view) most important things that show how
z3c.form works. it should be a lot easier studying z3c.form from this chart,
but combined with looking at the sources, if more detailed knowledge is
needed (and maybe i forgot a detail here and there :). all those hooks are
bold, interfaces are yellow and functions red. the file is in pdf-format and
the graph therefor is a vectorgraphic.
but subform- and groups-package are missing.
hope this helps. at least it should be a nice overview that prevents you
from looking at the sources too often. here it is:
View this message in context:
Sent from the Zope3 - users mailing list archive at Nabble.com.
Zope3-users mailing list