cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: various cforms issues
Date Fri, 13 Oct 2006 14:34:16 GMT
Marc Portier wrote:
> 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'

That's what I said: +1, meaning "I agree", "Yes, it should be fixed.". Even if 
you could hack field to act as output, output itself should function correctly.

>> <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

I skipped union just 'cause I've not used it and hence have no opinion on it.

>>> 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
> from
>     public void readFromRequest(FormContext formContext) {
>         if (!getCombinedState().isAcceptingInputs()) {
>             return;
>         }
> and if you'ld handle it through output, and use flow to set the value
> there is no request reading at all:
> from
>     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)

You are probably right, but I'm not sure. I think there were some discussion 
about skipping reading of fields missing on the template, which sounds related 
to what you are talking about.


View raw message