>>> - There is a problem with properties. A component is possibly based on the
>>> generic attribute map and has no setter for a property. e.g. function Name
>>> property in ValidatorScript.
>>>
>>> At the moment Clay has no knowledge about such attributes and it's
>>> impossible
>>> to do a type conversion. I think something like this is needed:
>>>
>>> <component jsfid=3D"validatorScript"
>>> componentType=3D"org.apache.shale.ValidatorScript"/>
>>> <properties>
>>> <property name=3D"functionName" type=3D"String"/>
>>> </properties>
>>> ...
>>> </component>
>>>
>>> Which could be optional if a setter exists.
>>
>> This is defiantly a shortcoming. Originally I was thinking about allowing
>> custom chain
>> commands to be registered by the clay component like the Shale servlet
>> filter provides.
>> That would allow custom commands to be plugged into the chains used to
>> construct the
>> subtree. The same solution would work for registering custom builders rules
>> used to
>> associate an html element with a faces component when using the html layout
>> strategy.
>
> Properly designed components will exhibit "attribute-property
> transparency" (like the standard components do), so this might not be
> as big an issue as it sounds like. In particular, the following two
> calls will have exactly the same effect:
>
> component.setFoo("bar");
> component.getAttributes().put("foo", "bar");
Craig,
Yes, as long as the attribute is a String or the component knows how to convert
the String and
there is no typo in the attribute name there is no problem.
However a solution is needed to validate attribute names and do data conversion
for components
that don't expect a String.
Manfred
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
