On Thu, Jan 22, 2004 at 07:20:28PM +0100, Sylvain Wallez wrote:
> [EMAIL PROTECTED] 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.
>
> WDYT?
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?
<sudden-thought>
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.
</sudden-thought>
WDYT?
--Tim Larson
