On 2006-08-28, at 12:00 EDT, Jim Grandy wrote:
> Just throwing out a possibility; maybe someone already has a proposal
> for constraint type coercion that we could revive?
Adam has proposed that the compiler should automatically coerce $path
constraints according to the declared type of the attribute.
I've countered with the idea of 'presentation types' which allow
defining arbitrary mappings from representation (e.g., strings) to
value (i.e., Javascript type).
I think this boils down to: do we treat constraints as a special
thing that have to have their value converted, or do we create a
general mechanism for attributes that defines a mapping between
representation and value? (Sometimes called 'swizzling' in OO
databases.)
I think the $style constraint makes it clear that a more general
mapping is needed. For example, consider font-size, which is a
number in LZX, with an implicit unit of (device?) pixels, but in CSS
is expressed as a string that must be parsed into a number and a unit
(which may be either a relative or absolute unit (and where pixels
are a relative unit dependent on output device resolution and
expected viewing distance!)).
Adam has also discovered that a general mapping is needed for data-
backed forms, since forms input and output data as strings, but the
database wants to store typed values.
Here's a combined proposal:
//---
// PresentationType
//
// A presentation type is a specification of how to map a Javascript
type to a String
// representation
//---
class PresentationType {
function accept(value) { return value; }
function present(value) { return value; }
}
2 new methods on node, acceptAttribute and presentAttribute
//---
// acceptAttribute
// @param name:String the name of the attribute
// @param type:PresentationType
// @param value:String the string representation of the desired value
//
// Sets the named attribute to the result of converting the value
using the
// type's accept method
//---
function acceptAttribute(name, type, value) {
this.setAttribute(name, type.accept(value));
}
//---
// presentAttribute
// @param name:String the name of the attribute
// @param type:PresentationType
// @returns value:String
//
// Returns the value of the named attribute converted to a string byt
// type's present method
//---
function presentAttribute(name, type) {
return type.present(this.getAttribute(name));
}
//---
// Example presentation type
//---
class BooleanPresentationType extends PresentationType {
function accept(value) {
switch (value.toLowerCase()) {
case "0": case "false":
return false;
default:
return true;
}
}
function present(value) {
if (value) {
return "true";
} else {
return "false";
}
}
(And so on, for other types.)
Define a mapping table from the space of types for attributes to
PresentationTypes.
Finally, for $path and $style constraints, the compiler will emit a
constraint function that uses `acceptAttribute` to bind attributes,
rather than setAttribute, according to the mapping table.
[There is another dimension here that we can add at a later time:
the representation type in this proposal is as a string. You could
imagine other representations, e.g., graphical representations.]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
