just found a small glitch in the aggregate-binding which is somewhat related to a broader discussion IMHO
(yeah, I know its related to the bug we closed only yesterday, just that I found out a nicer test after that)
[just an apetizer]
The context under which I found the issue:
- definition holds an aggregate-widget (stolen from the aggregate binding sample from Vadim) the thing has:
- @id='date'
- split parts 'day', 'month', 'year' all of type integer
- an own datatype of 'date',
- the month field has a selection-list mapping e.g. 4 to 'April'
- to the front end I style this widget to show the seperate parts in stead of the one combined one
- on the backend I however have only one 'string' holding the date, so I have a simple value-binding with a date-convertor that directly maps that onto the 'date' widget
when I bind "07/04/2004" to the widget and show the form I get out the tree html-inputfields you'ld expect, but with "string" not "integer" values, i.e.
- day shows "07"
- month has a fi:value of "04" causing the select-box not to show "April" but "pls select a month"
- year shows "2004"
the reason to this?
a setValue from the binding on the aggregate-field eventually calls the setFieldsValues() in there, which splits the string-value of the combined widget into it's parts and sets it on them by allowing them to partField.readFromRequest(newValuePart) which will set on those fields the 'enteredValue' (and mark the 'needsParse') but not the 'value'
between this and the moment that generateSAXEvent reads out the split-part fields the value is never set (meaning the integer convertor never comes into play) resulting in the sax snippet to smash in the 'enteredValue' since the value==null
of course the solution is clear to anyone: after letting the readFromRequest() I should just getValue() on the part-fields
(honestly? - getValue while I really want to set them? - readFromRequest while there is no http-request at all?)
Index: AggregateField.java
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/AggregateField.java,v
retrieving revision 1.3
diff -u -r1.3 AggregateField.java
--- AggregateField.java 9 Mar 2004 13:17:26 -0000 1.3
+++ AggregateField.java 8 Apr 2004 06:30:23 -0000
@@ -149,6 +149,7 @@
// Fields can have a non-string datatype, going to the readFromRequest
Field field = (Field)fieldsById.get(splitMapping.getFieldId());
field.readFromRequest(result);
+ field.getValue();
}
} else {
resetFieldsValues();
I'm a bit reluctant to check this in since as far as I understand this will also fire the validation on the object, which (again AFAICS) should be without danger in this case, but kinda blows high over what is really needed here...
[the main course]
widgets are complex babes but our current code structure
(naming, atomicity and resposibility of its methods) isn't really helping me... well, actually it might be useful for more people then just me to clear the confusion out...
in stead of trying to guess from current code, I'ld like to get a hold of what (and why) should happen from a higher level, and from there use that knowledge to try clean up, refactor and make self explaining what we have since now IMHO we've ended up in some historical soup which is soon going to prevent us from effectively add features or fix bugs
if this is only my limited view of things just say so, in the other case: who wants to take a first stab?
What is the state-machine behind the widgets/fields?
-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]
