Manfred
> >> - 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.
This looks correct. Is it possible that you have named two components the
same, sharing the same id of "amount" on the page? Try removing the id
attribute and let clay generate one - your patch :-). I'll see if I can
recreate this. It might also be that the digester rules are not registered in
the correct order.
>
> >> - 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.
>
> >> - 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.
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.
A suggested naming convention would seem the simplest.
<component jsfid="acme:outputText" extends="outputText"/>
<component jsfid="shale:outputText" extends="outputText"/>
>
> > 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.
Under the current schema, what you have described is available. You should be
able to define common elements as Components and then nest them under other
components as elements.
For example, you could define common labels used on all pages of your
application.
<component jsfid="baseAmountLabel" extends="ouputLabel">
<attributes>
<set name="value" value="Amount:"/>
<set name="style" value="color: blue"/>
</attributes>
</component>
<component jsfid="employeeData" extends="panelGrid" >
<attributes>
<set name="columns" value="2"/>
</attributes>
<element renderId="1" jsfid="baseAmountLabel" >
<attributes>
<set name="for" value="requiredAmount"/>
</attributes>
</element>
<element id="amount" jsfid="requiredAmount" renderId="0">
<attributes>
<set name="value" value="#{validate$test.amount}"/>
</attributes>
</element>
</component>
The clay meta component can be defined at any level of granularity. They can
be a simple component or a complex container graph. Just like in AWT, the
container is a component.
Gary
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
