cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject [cforms] widget values: set, get, validate, readfromrequest, parse, fireEvents,... generateSAXEvent
Date Thu, 08 Apr 2004 06:54:36 GMT
Hi there,

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

  - getValue while I really want to set them?
  - readFromRequest while there is no http-request at all?)

RCS file: 
retrieving revision 1.3
diff -u -r1.3
---	9 Mar 2004 13:17:26 -0000	1.3
+++	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.getValue();
              } else {

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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message