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 Field.java 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 together) 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 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]
