Manfred,
Thanks for the questions and for the help with patches too.
> Some questions and suggestions that may need further discussion:
>
> - 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.
>
> - 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. I think something like this is needed:
>
> <component jsfid="validatorScript"
> componentType="org.apache.shale.ValidatorScript"/>
> <properties>
> <property name="functionName" type="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.
>
> - 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).
Namespaces might be cleaner. I'd like to see an example.
>
> - I think that it would be a nice possibility to have a component without
> componentType to define components without common parent.
> Something like this:
>
> <component jsfid="aField"/>
> <element jsfid="outputLabel">
> <attributes>
> <set name="value" value="#{messages["components.fieldName"]}" />
> <set name="for" value="inputField"/>
> </attributes>
> </element>
>
> <element jsfid="emptyOutputText"/>
>
> <element jsfid="panelGroup">
> <element id="inputField" jsfid="inputText">
> <attributes>
> <set name="value" value="#{managed-bean-name.value}" />
> </attributes>
> </element>
> <element jsfid="errorMessage">
> <attributes>
> <set name="for" value="inputField"/>
> </attributes>
> </element>
> </element>
> </component>
>
> <component jsfid="aPanel" extends="panelGrid">
> <element jsfid="aField"/>
> </component>
>
> Whereby the elements from aField are directly added to the panelGrid.
>
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.
<component jsfid="myPanel" extends="panelGroup">
<element renderId="3" id="inputField" jsfid="inputText">
<attributes>
<set name="value" value="#{managed-bean-name.value}" />
</attributes>
</element>
<element renderId="4" jsfid="errorMessage">
<attributes>
<set name="for" value="inputField"/>
</attributes>
</element>
</element>
</component>
<component jsfid="myPanel2" extends="myPanel">
<element renderId="1" id="inputField" jsfid="label">
<attributes>
<set name="value" value="My Field" />
</attributes>
</element>
<element renderId="3" jsfid="outputText">
<attributes>
<set name="value" value="#{managed-bean-name.value}"/>
</attributes>
</element>
</element>
</component>
In this example, "myPanel2" extends "myPanel" that extends "panelGroup". In
this case, "myPanel2" adds a label child component and overrides the inputText
component with an outputText component.
The "element" definitions are kind of like a java inner class. The jsfid is
the component that is included and the renderId is the instance name. The
element can override attributes of the included\extended component. The
included component can be a simple or complex graph of components. Circular
inheritance is checked at startup.
>
> Comments welcome.
>
> Manfred
Gary
>
> ______________________________________________________________
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
