Re: css_class value not propagates to subfields of DateTime form

Hi Kit,

 [...]
 > >  The bug can be fixed via a simple "on_value_css_class_changed" helper;
 > > however on the formulator-general list I have been uncarefully discussed
 > > the option of having different css-classes for the date and time values.
 > > 
 > > As nobody came up with a real use case for this I guess there is no use
 > > case for it.
 >  
 > Uhm, there is one in my head. Required fields get a different background
 > color. The datetime field can have required date fields, but the time
 > fields can be optional. It would good to make this visually apparent.
 > 

 Argh, why did I asked again, I should have known  ... ;-)
 
 ... hm, with the "allow empty time" field this use case makes sense to
me. I have not noticed the little checkbox all down of the ZMI form so far...


 > >  So if nobody objects on this list I will check in the simple fix
 > > sometime near the end of the next week (after I found the times to write
 > > tests for it :-> )
 >  
 > I hope I haven't made your simple fix more complicated :)

 It is not getting that complicated. It would contain the following steps:

 - the DateTimeField will get another value, say "css_class_time"
 
 - there will be two on_change_* hooks

 - the ZMI form for the DateTimeField will get another field
   to set the class for the time sub-fields

well, the patch would contain more than four lines.


 The tricky part (for me) are the semantics of the new "css_class_time"
field:

 a) if css_class_time is set, render the time fields with that class,
    but leave them class-less otherwise.

    This makes the user fill in to identical values in the "normal"
    case, where both date and time classes are identical

 b) if css_class_time is set, render the time fields using that class.
    otherwise check the "css_class" value used for the date fields,
    and use that class. finally if neither of the values is set, 
    leave the time fields class-less.

I feel this is mainly an UI issue; I am not quite sure which on the both
semantics meets the "principal of least surprise" for the user. 
I am somewhat biased to variant a) (maybe because the implementation is
simpler ;-). On the other other hand b) mimics somewhat the behaviour of
the "required/allow empty time" checkboxes in the validator section.

 As my judgement concerning UI issues is rather poor (usually I make
an arbitrary decision, only finding out after a few weeks the other
alternative would have been better), I am asking the list if anyone does
have an opinion about the semantics issue.

 If everybody feels as vague about it as me, I would prefer just to
fix the css_class-bug and do not implement the new feature of a separate
css-time-class -- better don't put a feature in as put it in in a bad
shape ... 


Cheers,
Clemens