Return-Path: 
 <dev-return-48273-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 92021 invoked from network); 28 Sep 2003 16:42:56 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 28 Sep 2003 16:42:56 -0000
Received: (qmail 35421 invoked by uid 500); 28 Sep 2003 16:42:46 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 35382 invoked by uid 500); 28 Sep 2003 16:42:45 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 35369 invoked from network); 28 Sep 2003 16:42:44 -0000
Received: from unknown (HELO mwinf0604.wanadoo.fr) (193.252.22.25)
  by daedalus.apache.org with SMTP; 28 Sep 2003 16:42:44 -0000
Received: from anyware-tech.com (AToulouse-206-1-3-48.w81-50.abo.wanadoo.fr
 [81.50.192.48])
	by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 67DC52800147
	for <dev@cocoon.apache.org>; Sun, 28 Sep 2003 18:42:47 +0200 (CEST)
Message-ID: <3F770F87.7080900@anyware-tech.com>
Date: Sun, 28 Sep 2003 18:42:47 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
X-Accept-Language: fr, en, en-us
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Event handling in Woody
References: <3F6A27D8.4010506@anyware-tech.com>
 <3F6ACFFD.7020400@outerthought.org> <3F6B0466.4050403@anyware-tech.com>
 <3F6B1F2D.1010704@outerthought.org> <3F6B2977.5010005@anyware-tech.com>
 <3F6B7D3E.7000402@outerthought.org> <3F6C4D27.1040602@anyware-tech.com>
 <3F720150.6090208@outerthought.org> <3F73FFD6.6050808@anyware-tech.com>
 <3F7705A4.9090907@student.tuwien.ac.at>
In-Reply-To: <3F7705A4.9090907@student.tuwien.ac.at>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Andreas Hochsteger wrote:

> Hi Sylvain!
>
> Sylvain Wallez wrote:
>
>> <snip/>
>>
>> I solved points 3&4 as follows :
>> - <wd:action> are considered as "intra-form" actions : they never 
>> validate and always redisplay the form
>> - <wd:submit> (new widget that extends action) are considered as 
>> "form-exit" actions. They have an additional "validate" attribute 
>> that define if form validation should occur (true by default). For 
>> example, this allows a "cancel" button to be written as <wd:submit 
>> id="cancel" validate="false"/>
>
>
> Would it be possible (perhaps in the future) to handle those 
> intra-form actions completely on the client (eg. via JavaScript)?
> Imagine using some DHTML to add or delete rows...
>
> Not that I'd need it right now, but I'm just curious, if you thought 
> about something like that.


Yes, I thought about that, and I even wrote some add/remove stuff for 
XMLForm before switching to Woody. But this can be very tricky to do as 
it highly depends on how the form widgets map to HTML code.

And since this mapping is defined by the form template, you can't rely 
on the fact that a repeater is laid out in a particular way. This could 
be done, however, if the layout of a repeater was templated using a new 
instance-only widget like the wi:group defined in "woody-page-styling.xsl".

Now the repeaters are only a small part of event-handling, as actions 
can be used to do many other things such as getting the (parsed and 
validated) value of other fields, accessing application data, etc. This 
server-side event handling allow to simply define complex form 
interactions at the cost of a roundtrip to the server. I'm currenlty 
investingating in moving form styling on XSL-enabled clients (Mozilla 
and IE6) which would speed up this rountripping.

Now handlers involving widgets only (and not app-data) may be sent to 
the client, but this would require to reconsitute an equivalent of the 
form model on the client. Not easy, but I'm not a client-side JS 
expert... Want to give it a try ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com