cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [Woody] We need a booleanfield at all?
Date Thu, 22 Jan 2004 19:59:53 GMT
On Thu, Jan 22, 2004 at 07:20:28PM +0100, Sylvain Wallez wrote:
> wrote:
> >On Thu, Jan 22, 2004 at 04:28:29AM -0600, Antonio Gallardo wrote:
> Honestly, I don't think speed is the real issue here...
Agreed.  I was just trying to show that speed issues could be
decoupled from definition syntax issues.

> IMO, this concern belongs more to the convertor than the datatype, as 
> the convertor sits between the request parameters and the datatype and 
> is in charge of converting these parameters from/to the datatype.
> Furthermore, the value of the "null" attribute has to be converted into 
> the target datatype, and this is again a convertor job!
> And more: the boolean datatype can have two convertors. The default one 
> will consider null as false, which will automagically handle HTML 
> checkboxes. A second one, will consider null... as null and can be used 
> for tri-state booleans.

Ok, I agree that the decision of how to translate null parameters is the
responsibility of the convertors.  Are we happy with just a 3-state
boolean if we just start respecting the "required" attribute to turn it
into a 2-state boolean?  I think this setup would work well with the
two converters you suggest, but still wonder about giving all the
converters a null="some-value-or-maybe-an-expresson" parameter...

> >Optionally, for HTML checkbox rendering we could have the template
> >generator/processor check to make sure that the "null" attribute
> >is not missing or set to equal "null" for boolean valued fields.
> >This would help prevent people from tripping over the mis-design
> >of the HTML spec's handling of checkboxes.
> Mmmh... I'm not sure this is so simple, as the template engine doesn't 
> know what the final rendering will be. What about my proposal above?

  Conversion could be seen as logically a property of
  the view rather than of the model.  For example, why
  should the model determine the date format that the
  user is allowed to enter?  This is a presentation
  concern that the model should not even be aware of.
  Our current design is a side-effect of treating the
  view as a one-way template instead of as a full
  layer like the binding.

  Notice how our specific pattern approximates a much
  more general pattern:
    Beans<-->Binding   <-->Model<-->Template  <-->HTML
    Data <-->Conversion<-->Data <-->Conversion<-->Data
  We have the same concerns when binding as when
  templating, we just happen to use different names:
    value/attr/property <-> input field
    insert-node/bean    <-> inline markup
    binding direction   <-> normal vs output styling
    custom binding      <-> custom stylesheet
    convertor           <-> (currently missing)

  Perhaps these parallels could be exploited to permit
  the binding and view to be supported by the same code.
  We would then initially have three standard bindings:
    Java beans, XML, and HTML
  More could be created as needed, such as Mozilla XUL,
  and of course this would not prevent the continued
  use of templating and stylesheeting tools; just use a
  custom template in one binding direction and the new
  HTML binding to cover the other direction, no extra
  coding required.

--Tim Larson

View raw message