Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Wed, 21 Apr 2004 02:24:25 +0100
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: Re: [cforms] refactoring questions (was Re: cvs commit:
 cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel
 Struct.java Messages.java Repeater.java MultiValueField.java
 AbstractContainerWidget.java Output.java Upload.java Action.java Form.java
 ContainerDelegate.java AbstractWidget.java Field.java Union.java
 BooleanField.java Widget.java)
Message-ID: <20040421012425.GE27508@keow.org>
References: <20040420221928.11898.qmail@minotaur.apache.org>
 <4085A446.5050103@outerthought.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4085A446.5050103@outerthought.org>
User-Agent: Mutt/1.3.28i

On Wed, Apr 21, 2004 at 12:29:26AM +0200, Marc Portier wrote:
> mpo@apache.org wrote:
> 1/ should getWidget(id) be removed from Widget? It is already on 
> ContainerWidget (which is the true context that makes sense IMHO)

+1 remove it.  It is historical from before we had the Container* code.

> 2/ should getNamespace() exist at all, it seems to return the same thing 
> as getFullQualifiedId()? Maybe a historical idea waiting to get thrown out?

+1 historical, just make sure getFullyQualifiedId() does not break.

> 3/ can getId() ever return null or "" on a widget instance? Can't we 
> carefully asume programming error and allow for the accidental NPE to be 
> thrown

+1 after we fix the top-level "form" widget to not return null or "".
(I don't remember which, but it returns one of those two values).
Anyway, we somehow need to supply the "form" widget with an id to resolve
widget naming conflicts when there is more than one form on a page.
I think it should come from somewhere other than the form definition,
because it is the page designer's role to prevent form id conflicts, not
the role of the form designer.  For example, imagine a page containing
two instances of the same form definition, tied to separate data.  The
page designer knows there is a conflict, but the form designer has no
way to prevent it.  Maybe there is a way to auto-generate the id's?

> 4/ same question on getDefinition()

There once was talk about the possibility of widgets without
definitions: http://marc.theaimsgroup.com/?t=107165245100001&r=1&w=2
Does this have any relevance to your question?

> 5/ should we rename ContainerDelegate to simply WidgetList (and the 
> ContainerDefintionDelegate to WidgetDefinitionList)

+1 to something like that.

> 6/ union seems to generate fi:field in stead of fi:union this surprised 
> me a bit, is that the goal?

Yes, I was trying to surprise you ;)  No, really I just noticed that
this part of the "union" widget acted just like a field as far as the
template layer was concerned, so I used the same name to prevent having
to copy-and-paste support code in the template handling.  A better route
might be to change both field and union to use something more generic
like fi:value in the templating layer.

> 7/ should validation stop as soon as possible or continue to allow all 
> validation errors to be set?

Don't know which is best.  *If* we cannot decide (due to different needs
in different usecases) then we will need to add an attribute to let the
form designer control the behaviour.

> 8/ setParent() on abstractWidget should be write-once IMHO, possibly 
> yielding RTE (IllegalState?) when someone tries to reset it

See: http://wiki.cocoondev.org/Wiki.jsp?page=ImmutableWidgetDefinitions
The widget-definition repositories will allow widget-definitions to have
multiple parents, so imho we should remove setParent() completely.
Please see the "Walker solution" on that wiki page for more details.

> 9/ should not all generateSAXFragments include the 
> getDefinition.generateDisplayData() by default

+1 if my memory of the issues serves me right.

> -marc= (the happy cleaning lady, be warned: she'll be back :-))

Yes, please come back.  We need to get this house in shape. :)

--Tim Larson