Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
To: users@cocoon.apache.org
From: Joerg Heinicke <joerg.heinicke@gmx.de>
Subject: Re: Show/Hide Widgets
Date: Fri, 2 Jul 2004 22:40:59 +0000 (UTC)
Lines: 56
Message-ID: <loom.20040703T000653-892@post.gmane.org>
References: <cbmhkc$2to$1@sea.gmane.org> <40E21108.3030109@gmx.de>
 <40E2811F.2050802@lineone.net> <40E28C36.2040405@gmx.de>
 <40E29079.2030300@lineone.net> <40E2F9FF.60106@gmx.de>
 <40E3E642.90208@lineone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
Sender: news <news@sea.gmane.org>

Vilya Harvey <vilya <at> lineone.net> writes:

> > This means validation is caused by them though it should not?
> > http://cocoon.apache.org/2.1/userdocs/forms/widget_submit.html
> 
> Yes. It also means that execution is resumed in the flowscript that sent the
> page, if the validation passes.
> 
> I've created a simple example which demonstrates the problem. I can't attach
> it as the mailing list doesn't accept zip files, but if you have the time
> and are willing to look at it then drop me a line and I'll email it to you
> directly. I'd really appreciate that.

A perfect testcase to simplify developer's life: unzip, copy, start Cocoon,
request - I love that. Thanks. 

The good news: It is not an error in the implementation, but in your form
definition. But it's still a "not so intuitive" implementation then.

The reason: A request is processed by traversing through the tree and processing
all widgets (readFromRequest() and validate() and so on). The effect you saw was
caused by not processing the cancel widget at all, so the submitWidget of the
form was not set correctly and the form assumed you hitted submit.

The errors: Two errors have been in your form definition.
The first one is hinted on at http://wiki.apache.org/cocoon/TimLarson
#head-72d1bc1786787b9f5cf6f8701a1fb442f4f59285-2 :
"A container widget (Repeater, Struct, Union, or sort-of AggregateField) must be
used for union cases that need to hold multiple widgets." While the union
binding and the union in the template have an explicit case, the form definition
has not (but obviously an implicit one) and you have to use a container widget
for it. Additionally the container widget must have the id of the caseWidget's
value, here 'editingInt'. Union processing continues only for its children named
like the caseWidget's value.
The second error was fd:field for your case/control widget 'editIntControl'. So
the value will always be read from request and as you did not provide an input
field for example, it will always be null. Changed it to fd:output, so it won't
be read from request, and it works now.

The solution (hoping that Tim also reads it):
The implicite cases are really hard to understand, especially as there is
fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
template and binding (I have to add them there too to get the same tree) and
complicates them unnecessarily. Why don't we simply introduce explicite fd:case
- until we have masks ;-)

WDYT?

To Vilya: That's a very nice sample of using union. As I was searching for a
simpler sample than the Form Model GUI do you want to provide it to the project?
Maybe with the "real" functionality of editing a row as for the moment one can
only cancel the editing. Would be really cool - and I have less work to do ;-)

Thanks,

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org