cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Binding "on-insert-row" is ignored
Date Sun, 13 May 2007 19:37:30 GMT
Dev at weitling pisze:
> Hi Grzegorz, Alessandro and Jason,
> Well, if I understood it right what you three pointed out, the process
> is as follows:
> 1. create the form plus binding
> 2. create the bean holding the initial values
> 3. on form.load() fill the widgets from the bean by copying its
> structure and values
> 4. on row creation build new widgets

right, by using event-handling.

> 5. on get the values form the widgets and fill the bean,
> calling the fb:on-insert-row "addmethod" for new repeater rows as necessary
> So this would mean
> 1. big memory consumption because data is doubly hold by two different
> structures (bean and form-widget-whatever)

It is done that way because ORM tools work with beans not forms. It's perfect example of seperation
of concerns that 
Cocoon aims to provide at every stage of webapp creation. It's Cocoon's philosophy that has
several strong advantages.
Are your structures so big that you must care about this point?

> 2. a non-live connection between the form and its bean model

Again, it's design principle to update data in transactional manner so for example other users
do not see partially 
updated questions.
Why do you really need this live connection?

> 3. error-prone row creation because some data might be lost


> Let me explain item three: I have nested repeaters in a kind of multiple
> question form where the user may create a new row holding a new
> (possibly correct) answer (=answerRepeater). Inside there is a nested
> repeater holding answer text in different languages. When a new row is
> created there not only a number of answer text fields has to be created,
> but they also have to be connected with a language hold by a list. I see
> a problem there. And it looks as I have to put the cart before the horse
> with putting the action for data updating in the definition, partially
> in the flow and clean-up in the binding.

I don't follow you here. In your situation you need only to create rows of several repeaters
dynamically but by no means 
you have to mess up with form definition/binding at runtime. In fact, it should be rather
easy to write form definition 
and binding that would handle all the structures that user is allowed to create.

Really, binding will handle them. Please explain your exact problem little more.

> Besides my special problem, what about extending the binding for
> (structure-)updating? What about let the bean hold the structure and
> data in a more live way?
> I know this might be offending, but if (...) my bosses let me go we
> could discuss this at GetTogether :-)

Florian, you really have to provide *strong* arguments to make us change architecture of Forms
framework and abandom all 
the patterns of web programming ;-)
Explain please why you really need this live binding so we could help you more.

Grzegorz Kossakowski

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message