cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject various cforms issues
Date Thu, 12 Oct 2006 15:06:10 GMT
Hi there,

In a small cforms demo I'm trying out today I've been hitting quite a
number of issues. Each of these are (some even important) bugs IMHO, I
still need to perform a full scan of jira and svn history to see if some
of these are known and/or understand how we got here...

this upfront message is a poll for checking if I'm making sense at all
here, possibly tapping from your combined memory to be corrected on these.

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.

2/ union.readfromrequest should stick to the contract of the method:
reading 'own values' from the request and passing it down to active
children that might get new values set from the request

it is currently not doing so, in stead, it is:
-a- causing the bound 'case-widget' to readfromrequest (which in fact
doubles the call on that instance: their common parent-widget, and only
he, should be driving that already!  Please note: the order of things
should not effect us: the union widget is listening in on
value-change-events on the selector-widget, so there is no need to force
the case-widget to read from the request...)

-b- and then using this new value to activate the new case-child and
letting that read its values from the request

I find this awkward for 2 reasons:
 1 > duplicating call again: the union should just be waiting for the
value-changed-event and react on that,
 2 > and more importantly, it doesn't seem to make sense: how could
there be values in the request params for these newly activated
widget-group (these are matching the new case, so they weren't shown on
the form yet)

(I've found cocoon-1195 to be related, don't really get what is
happening here yet, anyone?)

Proposed fix: bring readfromrequest back to an essential form where it
just delegates to the current case-widget-group (or the 'previous' if
you like, since that new request-submit might be changing the case all

3/ union currently waits for getChild(anyId) to initialize the newly
needed case-group. However the getChild(newCaseValue) is currently not
called from the valueChangeListener on the caseWidget

one serious side-effect I've seen from this is that in certain cases (a
nested union in a new/class construct) the getChild will not be called
until the generation-pipeline is at work!

At that moment however child-group initialization is causing a load of
new events to be happening (value-changed caused by initial-values, as
wel as create-events).

Conceptually: it is my believe that all these events should have been
fired/handled during form.process, not during the publishing (suppose
publishing doesn't visit them, the server side 'state' of the form-model
is not as it should be)
Technically: having these occur during the publishing-pipeline also
causes the attached javascript event-handlers to be operating in a
context lacking the flow-scope (cocoon undefined, functions in the flow
not available, etc etc)

4/ field should not turn to 'null' when the matching parameterName was
not present in the request.

Given the way browsers work I believe that BooleanField is the only
exception to this. (html-checkboxes will not be present in the

To be honest: I'm currently only having a practical issue with this
because of the combination of above issues being around, but
conceptually I think we need to check before interpreting the lack of
any new value as a motivated change of the value to null ?

any comments welcome,
I'm currently planning to investigate deeper into these in the nearby future

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

View raw message