Typed/defaulted binding values in NGComponent (replacement for ERXComponent's stringValueForBinding( name, default ) and friends) #91

Summary

NGComponent has no way to read a binding with a default, or as a given type. The only typed accessor is the deprecated stringValueForBinding( String ) (NGComponent.java, marked with a FIXME as a migration bridge), so ported code ends up with casts and null-juggling.

Where this came up

Porting a small Wonder app (Vacation) to ng 0.1.6-SNAPSHOT. ERXComponent code like

public String title() {
	return stringValueForBinding( "title", "Svaka partí" );
}

became

public String title() {
	return Objects.requireNonNullElse( (String)valueForBinding( "title" ), "Svaka partí" );
}

It works, but it's noisy, and the unchecked cast just moves a ClassCastException to the call site when someone binds the wrong type. Every Wonder app has dozens of these (stringValueForBinding, booleanValueForBinding, intValueForBinding… with defaults), so it's one of the most common edits in a port.

Possible directions

Not a proposal, just the design space:

• Typed pull with a default: valueForBinding( "title", String.class, "Svaka partí" ), failing with a clear message naming the binding and the bound type when the types don't match.
• Convenience overloads à la ERXComponent (stringValueForBinding( name, default ), booleanValueForBinding( name, default )). Familiar to WO devs, but it's the API the FIXME wants to get away from.
• Declared/typed bindings: the component declares its bindings (types and defaults) once, e.g. in the .api file or a Java descriptor, and reads them through that. Bigger change, but it'd also give tooling and validation something to work from.

Boolean conversion is a related detail: whatever the API ends up being, it should probably follow NGAssociationUtils' truthiness rules rather than a plain cast.