Jean-Baptiste Quenot wrote:
> * 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.
>
ok, makes sense
obvious question then of course is why that formatting-convertor
couldn't be made to capture the 'null' and circumvent the replacement to
this '0' 'or 1/1/1970?
> 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.
>
well, I don't think it is garbage at all, it's a hook to add e.g.
attribute-nodes, those have reason of existence regardless of the fact
that there is a nested text-node or not.
suppose you don't have the flexibility to design the input-xml coming
from your backend and it doesn't look like
<dates>
<startdate />
<enddate />
<dates>
that can be optionally removed, but actually looks like
<dates>
<date event="start" />
<date event="end" />
</dates>
then you'll need to solve your issue differently as well
so I guess even for you it's only garbage in this particular case, no?
> 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.
no worries, mate, I'm glad we're taking and finding time and patience to
get to the core of this.
Anyways, this whole process of finding out what and how kind of
convinced me that we can in fact revert the change. (and not add an
attribute)
In the event that somebody might want to remove the element when the
nested text-node would be empty, then he/she should do so through the
nested on-update:
<fb:value id="x" path=".">
<fb:on-update>
<fb:javascript direction="save">
.. the logic to remove the path if new value is null,
</fb:javascript>
</fb:on-update>
</fb:value>
I understand that this is more typing then just adding a
@remove-if-null="true" (which was my earlier idea), but it's the kind of
explicitness that both holds more flexibility and fits better my feeling
that the ValueBinding by itself should not be altering the xml structure.
wdyt?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
