[Manfred Klug <ma...@web.de>]

>>> - 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org