cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: various cforms issues
Date Fri, 13 Oct 2006 13:40:55 GMT

Vadim Gritsenko wrote:
> Marc Portier wrote:
>> 1/ fd:output is ignoring fd:initial-value
>> this one is quite obvious I think: anybody adding a fd:initial-value to
>> a fd:output can wait for eternity for it to ever get applied.
>> Proposed fix: initialize() should do it like does.
> +1

I still think the fix should be applied, but given the current
widget-states I guess the same can be achieved through a proper 'field'

> <snip union/>

since you skipped issue 2/ and 3/, the ones concerning union, I'm
compelled to attracd again some attention to it: those are the real
important bugs IMHO

>> 4/ field should not turn to 'null' when the matching parameterName was
>> not present in the request.
> I'm not convinced we should change this. I suppose you need it only
> because 1/ does not work.

nope, this has nothing to do with initial-values on read-only widgets,
if you handle them with 'fd:field' then it will ignore reading the
request when it's not in an enabled state

    public void readFromRequest(FormContext formContext) {
        if (!getCombinedState().isAcceptingInputs()) {

and if you'ld handle it through output, and use flow to set the value
there is no request reading at all:

    public void readFromRequest(FormContext formContext) {
        // do nothing

actually I noticed this because of the union issues (2/ and 3/)

currently a 'fd:field' that is added through a selected case-group will
first properly initialize (and get its initial-value), and then gets
instructed to read-from-request (making no sense IMHO)

since that request couldn't be holding any value for this newly added
widget, the field changes its value back to null (cool he :-))

>> Given the way browsers work I believe that BooleanField is the only
>> exception to this. (html-checkboxes will not be present in the
> Multi-value field also will not have a parameter in the request if
> nothing was chosen.

ah, didn't know, thx for clarifying...

anyway, this 'multivalue' (like the  'boolean') aspect is something the
field would now, and could thus properly react upon, no?

I'm still compelled to ensure we're correctly interpreting missing
request-parameters, assuming it means 'setValue(null)' by default seems
a bit weird.  By default I think it should mean 'no change'.

(in fact that is precisely what is happening when those widgets are not
on the form because they're in a parallel union-case-group)

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message