Manfred
> >>>> - 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.
After the PropUtils patch is applied, an exception will be raised if the
attribute was not found. We could catch the exception and just add the
property to the attributes map? Should we try to validate that there is a
matching method on the component?
>
> >>>> - 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]
That looks good. Should we make some assumptions if the component jsfid or
extends attribute did not specify a qualifier? Or, throw an exception that they
must have a namespace? I kind of like the assumed default for the people that
won’t take advantage of the feature, but one could argue for consistency.
>
> >>>> - I think that it would be a nice possibility to have a component without
> >>>> componentType to define components without common parent.
> >>>> Something like this:
A simpler solution might be to let an extending meta component or element
override the component type. This way we could morph a outputText into an
inputText.
<component jsfid="h:outputText" componentType="javax.faces.HtmlOutputText" />
<component jsfid="h:outputAmount" extends="h:outputText>
<attributes>
<set name="value" value="#{managed-bean-name.amount}
</attributes>
</component>
<component jsfid="h:inputAmount" extends="h:outputAmount"
componentType="javax.faces.HtmlInputText"/>
This would give us the same flexibility but still make sure that the meta
component is associated with a JSF component. The only problem I see is that
this could be misused. For example, someone could extend a panelGrid and
override the type to an inputText.
If we allowed this flexibility, I think we would have to give up on the strong
checking of setting properties and just ignore the ones that don’t fit the
component.
> >>>>
> >>>> [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.
After the fix to the inheritance is applied, I think that this would be
resolved. It would allow you to define a panelGrid with a lablel and text
field as elements and then extend the pannel adding other elements.
<component jsfid="h:complexAmount" extends="h:panelGrid" >
<attributes>
<set name="columns" value="2"/>
</attributes>
<element renderId="10" jsfId="h:outputLabel">
<attributes>
<set name="value" value="Amount:"/>
<set name="for" value="h:outputAmout"/>
</attributes>
</element>
<!-- new component type override, morphing to another component? -->
<element renderId="15" jsfid="h:outputAmount"
componentType="javax.faces.HtmlInputText"/>
</component>
<component jsfid="h:complexPerson" extends="h:complexAmount" >
<element renderId="0" jsfId="h:outputLabel">
<attributes>
<set name="value" value="Full Name:"/>
<set name="for" value="h:outputAmout"/>
</attributes>
</element>
<element renderId="2" jsfid="h:outputText" >
<attributes>
<set name="value" value="#{managed-bean-name.fullName}"/>
</attributes>
</element>
</component>
<component jsfid="h:personForm" extends="h:form" >
<element renderId="10" jsfid="h:complexPerson"/>
</component>
Results in something like this:
<form....>
<table>
<tr>
<td><label>Full Name:</label></td>
<td>Fred Jones</td>
</tr>
<tr>
<td><label>Amount:</label></td>
<td><input type="text" value="0"></td>
</tr>
</table>
</form>
>
> [snip]
>
> 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]
