Gary
>>>> - Is there a reason why validators and converters (actionListeners and
>>>> valueChangeListeners too?) are not inherited by elements and extending
>>>> components?
Good that you have found the problem.
>>>> - 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'm not sure how we would allow for mapping non standard action event
> properties without this unless we went with Craig's suggestion of using the
> attributes map. Is that what your point toward? If so, this should belong in
> PropertyValueCommand.
We must use the attribute map anyway either in Clay or in the custom builder.
>>>> - 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).
>
> I think that if we had namespaces, we would have to create a composite id's
> for the component. It would need to be the jsfid and a namespace.
Yes.
> This would need to be considered when realizing inheritance. For example, you
> might have two outputText components registered under different namespaces.
> I'm not sure how the extends attribute alone would identify the correct super
> component unless it was assumed that you could only extend components defined
> in the same namespace? That might work.
The extends attribute is a jsfid, so it needs namespaces too.
I think something like this should work:
<view>
<namespaces>
<namespace name="h" value="theJsfHtmlNamespace"/>
</namespaces>
<component jsfid="h:inputText" componentType="javax.faces.HtmlInputText"/>
</view>
<view>
<namespaces>
<namespace name="standardJsfHtmlComponents"
value="theJsfHtmlNamespace"/>
</namespaces>
<component jsfid="dateInput" extends="standardJsfHtmlComponents:inputText">
...
</component>
</view>
[snip]
>>>> - 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.
>
> Under the current schema, what you have described is available.
Not completely.
> You should be able to define common elements as Components and then nest them
> under other components as elements.
Sure, but if I would like to always use a set of common elements together (e.g.
label *and* input field) I must add them every time separately.
[snip]
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]
