Gary,
>> - Is there a reason why validators and converters (actionListeners and
>> valueChangeListeners too?) are not inherited by elements and extending
>> components?
>
> The significance of the name is only for enumeration. I took this approach
> rather than adding another attribute to distinguish the type.
I think I use a short example to explain the question:
<component jsfid="requiredAmount" extends="inputText">
<converter jsfid="numberConverter">
<attributes>
<set name="minFractionDigits" value="2"/>
</attributes>
</converter>
<validator jsfid="clientRequiredValidator">
<attributes>
<set name="arg" value="#{messages['validate.test.amount']}"/>
</attributes>
</validator>
</component>
<component id="form" jsfid="clayValidatorForm" extends="form">
...
<element id="amount" jsfid="requiredAmount" renderId="0">
<attributes>
<set name="value" value="#{validate$test.amount}"/>
</attributes>
</element>
...
</component>
As result, the element in the form has no converter and no validator.
>> - 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. functionName
>> property in ValidatorScript.
>>
>> At the moment Clay has no knowledge about such attributes and it's
>> impossible to do a type conversion.
>> [snip]
>
> 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.
This could be a useful feature to manage complicated components, but I think
this is a bit oversized for the attribute problem.
>> - I think something like namespaces is needed for the jsfid attribut to avoid
>> name collisions between components of different sources.
>
> I believe that the component type registered in the faces config would have
> to be unique but I guess that you could choose to use the same jsfid? One
> approach might be to prefix the jsfid with a unique prefix (sunOutputText,
> myfacesOutputText).
Yes, this is a possible solution. But I know from own experience that different
people have different opinions about prefixes (short and cryptic against long
and meaningful).
> Namespaces might be cleaner. I'd like to see an example.
At the moment I have still no thought-out example. I wanted to hear your
opinion first before I further investigate to find a possible solution.
>> - I think that it would be a nice possibility to have a component without
>> componentType to define components without common parent.
>> Something like this:
>>
>> [snip]
>
> The basic idea was to associate a clay meta component to a JSF component
> using the componentType. The componentType would not be required for
> definitions that "extend" another component. The jsfid and componentType
> are mutually exclusive, one or the other.
>
> The default definitions are loaded for the view-config.xml file in the
> META-INF folder of the shale-clay.jar.
>
> In his fragment, the "panelGroup" is defined by default and loaded on
> startup.
>
> <component jsfid="panelGroup" componentType="javax.faces.HtmlPanelGroup" />
> <component jsfid="myPanel" extends="panelGroup" />
>
> The "myPanel" component extends "panelGroup" and will inherit the
> "componentType" and any elements defined under "myPanel".
>
> What's missing from your fragment above is the "renderId" attribute on the
> element. This is a sequence that is used to define composition under a
> component. The renderId is the "method signature" used when resolving
> inheritance besides defining the ordering. The "renderId" is a required
> attribute on the "element" node.
>
> You can define one component that extends another overriding or adding
> elements based on the "renderId" attribute.
> [snip]
Yes, and overriding or adding elements by renderId is a very nice feature.
But I'm looking for a possibility to define an arbitrary set of elements
without a parent and reuse this set in different places.
For example, this could be useful if you have the same input field
(including the label) in many forms. Define it once and use it everywhere.
Maybe, name it container instead of component.
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]
