Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Mon, 12 Apr 2004 16:15:38 +0100
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: Re: [cforms] widget values: set, get, validate, readfromrequest,
 parse, fireEvents,... generateSAXEvent
Message-ID: <20040412151538.GD12207@keow.org>
References: <4074F72C.9030704@outerthought.org>
 <4076942B.9030304@outerthought.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4076942B.9030304@outerthought.org>
User-Agent: Mutt/1.3.28i

On Fri, Apr 09, 2004 at 02:16:43PM +0200, Marc Portier wrote:
> Marc Portier wrote:
<snip/>
> >What is the state-machine behind the widgets/fields?

This would make an excellent wiki page.

> We jointly got the cforms internals code into a mess: too much features 
> have been hack-added (even worse: without updating javadocs) rather then 
> refactor-added.
<snip/>
> Wake up, people! This will not go away by ignoring it.
> 
> I do propose:
> - some refactoring of the kind
>   - introduce more granular methods
>     (e.g. to call parseValue() in stead of getValue() in all occasions
>      where the return is ignored anyway?)
>   - method/member renamings
>   - javadoc cleanups
>   - clean out the binding interface
>     (this will surely break class/new/union/ binding)
>   - solidify classes and interfaces by making immutables where possible 
> and appropriate (IMHO the form-definitions could benefit)
> 
> - finally fix the binding of the repeaters
>   - add a row-identity aspect to the repeater-rows
>   - ATM I even think it should combine multivalue-binding since that 
> looks strongly like another (unneccesary?) fork of the repeater-binding code
> 
> - get into adding the stuff from 
> http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad

+1 to the whole proposal above.  We need to get out of "alpha", and
this is the only way I see to get that to happen.

> While getting into above I'ld like us all to have the freedom to 
> (temporary) break things: the class, new, union, struct (possibly even 
> aggregate) comes to mind.

+1 from me.  I expect anyone else using those will welcome the better
designs we are hammering out on the WoodyScratchpad wiki page.

> This is not because I find those additions (nor the people that did it) 
> to be the target suspects for the current state of things.

None taken ;)

> Plus, the more stuff we break, the more reason there will be for more 
> hands to help in! (now from who did I learn that :-))
> 
> But seriouly: The above would be my main '-1' argumentation to anyone 
> proposing to do this in a separate CVS branch (just so you know) 
> (putting down some CFORMS_0.0.1 tag before on the cfroms block might be 
> meaningfull though)

Yes, if we are going to break things to re-set the bones, we need to tag.

> In any case looking for suspects is not the goal, nor is it to break 
> stuff.  It rather is about creating a clean basis to re-add the needed 
> features of the class/new/union/struct/repeater-binding allong the lines 
> of how we've been discussing them lately.
> 
> AFAICS it's this or keeping eternally waiting at the side of the 
> swimmingpool. (= mpo-logism for keeping cforms 'unstable')

We need to finish the design and get CForms stable, especially since
it is now the official forms framework.  I am going to go back to your
"Cubist Webapp" concepts and am trying to create some wiki page(s) to
express the CForms design from the standpoint of the user, visual
designer, event handler programmer, and data binding programmer.

--Tim Larson