Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4492CB27.5060108@apache.org>
Date: Fri, 16 Jun 2006 17:15:51 +0200
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] New ProcessingPhases added a repeater bug?
References: <44907A6E.2060804@agssa.net>
 <70AC564F-A148-416A-9F72-2CD8C0F660DC@leonid.de> <4491D535.5050205@agssa.net>
 <44925F19.8020909@apache.org> <4492C8A1.9020702@agssa.net>
In-Reply-To: <4492C8A1.9020702@agssa.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Antonio Gallardo wrote:

>>   
> It's not it does not work. The code was moved out because this seems to 
> be a better place for firing form events. This events are form events, 
> hence the form should fire them as needed. IMHO, the binding framework 
> does not need to know/care about special form needs.
Agreed

> 
> This can be fixed in a different way:
> While fixing this issue. We wondered why form.save() and form.load() 
> methods are defined only in form.js . This make pretty complicated to 
> call the binding framework outside flow (ie: from the actions). IMHO, 
> this methods belongs to form.java and in this way we can also not allow 
> an outsider class to call the following public methods:
> 
> informStartLoadingModel()
> informEndLoadingModel()
> informStartSavingModel()
> informEndSavingModel()
> 
> WDYT?
> 
Hmm, ok it sounds good to me to move code out of form.js into the Java
code. I think most of the code from form.js should be moved to be
available for cforms clients which do not use flow.
And protecting the above methods is good as well. The only thing I do
not know is if it is a good idea to add a dependency to the binding
package to the form class. So a general +1 for this.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/