Marc Portier escribió:
I'ld like to revert the fix so things are back to normal in the upcoming
2.1.10 release.
Yes, please. I though you already did it. :-)
I think we should not take things personally, we (committers) sometimes
makes mistakes and it is normal we are humans after all. Plea
Jean-Baptiste Quenot wrote:
> * Marc Portier:
>
>> 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)
>
> That is the simple way.
It's called an optimum: achieving the desired goal with the l
Jean-Baptiste Quenot escribió:
* Marc Portier:
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)
That is the simple way. But ending up with empty tags for all
widgets having the null
* Marc Portier:
> 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)
That is the simple way. But ending up with empty tags for all
widgets having the null value is not satisfactory. And th
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 ca
* 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
Jean-Baptiste Quenot wrote:
> * Marc Portier:
>>
>> Jean-Baptiste Quenot wrote:
>>> * Marc Portier:
>>>
Coming back to that original date issue in fact I'm afraid
I don't get it yet completely? At which time is this
'org.w3c.util.DateParser' active? How does
* Marc Portier:
>
>
> Jean-Baptiste Quenot wrote:
> > * Marc Portier:
> >
> >> Coming back to that original date issue in fact I'm afraid
> >> I don't get it yet completely? At which time is this
> >> 'org.w3c.util.DateParser' active? How does this become a
> >> problem
Jean-Baptiste Quenot wrote:
> * Marc Portier:
>
>> Coming back to that original date issue in fact I'm afraid
>> I don't get it yet completely? At which time is this
>> 'org.w3c.util.DateParser' active? How does this become a
>> problem of the binding?
>
> CForms was
* Antonio Gallardo:
> Jean-Baptiste Quenot escribió:
> >Namely and are known to be broken
> >in some cases.
> >
> Would you provide a test case in order to fix it and avoid a regression in
> the future? :-)
Not a testcase, but some facts.
-
Jean-Baptiste Quenot escribió:
Namely and are known to be broken
in some cases.
Would you provide a test case in order to fix it and avoid a regression
in the future? :-)
Best Regards,
Antonio Gallardo.
Hi,
I understand the concerns and I agree to keep the binding framework
backward compatible. It is important for our current user base moving
from older cocoon versions. Usually, adding a new attribute for handling
the new required behavior is the way how we have been resolving this
things be
* Marc Portier:
> Jean-Baptiste Quenot wrote:
>
> > I'd advise to write the binding using or
> > which is much more reliable.
>
> .. or even: don't use the binding framework and write proper
> cform-instance-traversal code in custom classes or flowscript
I second that.And wit
Jean-Baptiste Quenot wrote:
> Hello Marc,
>
> I understand your concern. Here is the reply I made on the JIRA
> issue:
>
> Just my opinion but this XML-based CForms binding API has a number
> of inconsistencies and bugs. I doubt that we will ever be able to
> find a syntax that fits all u
* Jean-Baptiste Quenot:
> Just my opinion but this XML-based CForms binding API has a number
> of inconsistencies and bugs.
Namely and are known to be broken
in some cases.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Hello Marc,
I understand your concern. Here is the reply I made on the JIRA
issue:
Just my opinion but this XML-based CForms binding API has a number
of inconsistencies and bugs. I doubt that we will ever be able to
find a syntax that fits all use-cases. I'd advise to write the
binding u
Bertrand Delacretaz wrote:
> On 8/8/06, Marc Portier <[EMAIL PROTECTED]> wrote:
>
>> ...since the mentioned fix however the effect of the 'null' in the 'text'
>> field is that the complete element gets removed (since that executes the
>> removePath() on ".")...
>
> Sounds like a bug to me, remo
On 8/8/06, Marc Portier <[EMAIL PROTECTED]> wrote:
...since the mentioned fix however the effect of the 'null' in the 'text'
field is that the complete element gets removed (since that executes the
removePath() on ".")...
Sounds like a bug to me, removing an element because an attribute is
nul
Hi there,
being late on upgrading some cforms sites I recently noticed an
incompatibility introduced in cocoon 2.1.9
since I'm unsure about the best way to handle, I just reopened the
jira-issue that ported the patch which led us here
[ http://issues.apache.org/jira/browse/COCOON-1687?page=
19 matches
Mail list logo
