Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 9 Aug 2006 17:01:04 +0200
From: Jean-Baptiste Quenot <jbq@apache.org>
To: dev@cocoon.apache.org
Subject: Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened:
 (COCOON-1687) [PATCH] JXPATHBinding : when saving the form,
 remove xml elements if the value of the widget is null])
Message-ID: <20060809150104.GJ2151@vision.anyware>
Mail-Followup-To: dev@cocoon.apache.org
References: <44D8471B.6090007@outerthought.org>
 <20060808102220.GC55043@vision.anyware> <44D871BB.9080603@outerthought.org>
 <20060808132559.GB18285@vision.anyware> <44D9E254.6000109@outerthought.org>
 <20060809133301.GI2151@vision.anyware> <44D9F1F3.4000800@outerthought.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <44D9F1F3.4000800@outerthought.org>
User-Agent: mutt-ng/devel-r804 (FreeBSD)

* Marc Portier:

> The argumentation of  the fix, namely to  make the value-binding
> remove an element upon 'save'  seems, currently, to be that this
> avoids after re-'load' some weird  formatting result (from "" to
> "1/1/1970")  in the  i18n  transformer caused  by some  external
> date-parser suggested in a patch that isn't applied?

You  may be  right  that  the date  problem  may  not happen  with
SimpleDateFormat  because  it is  lenient  by  default.  This  has
nothing  to do  with the  i18n transformer  however, but  with the
FormattingDateConvertor.

Now it's  up to you to  decide whether empty string  is garbage or
not.   For me,  it is.   Then your  proposal to  add an  option to
instruct CForms to remove the XML  node or to leave it empty makes
sense.

Anyway  I  should have  been  more  careful when  committing  this
incompatible change,  as you're  right most  Cocoon users  may not
have been impacted by this problem.
-- 
     Jean-Baptiste Quenot
aka  John Banana Qwerty
http://caraldi.com/jbq/