>>>>>> - 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.
Yes, the patch was the reason why I have found the problem.
> We could catch the exception and just add the property to the
> attributes map?
Yes, or we could always use the attribute map unless there is no attribute
definition. The required patch for PropUtils is relatively simple. The only
problem is the missing type information.
> 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 also think that we shouldn't force the people to use namespaces. But we
could allow a default value.
<namespaces default="myProjectNamespace">
...
</namespaces>
Which is empty if nothing is specified.
>>>>>> - 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.
And the people would spend a lot of time with the search for typos.
Another solution could be the definition of a pseudo component, which has a
special processing in CreateComponentCommand (or its own chain command).
<component jsfid="container"
componentType="org.apache.shale.clay.component.container"/>
<component jsfid="aField1" extends="container"/>
<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="panel1" extends="panelGrid">
<element jsfid="aField2"/>
<element jsfid="aField1"/>
<element jsfid="aField3"/>
</component>
<component jsfid="panel2" extends="panelGrid">
<element jsfid="aField2"/>
<element jsfid="aField1"/>
</component>
<component jsfid="panel3" extends="panelGrid">
<element jsfid="aField1"/>
<element jsfid="aField3"/>
</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.
Still a problem if I want to reuse the components in different combinations.
- complexAmount and complexPerson
- complexPerson and complexAddress
- complexPerson, complexAddress and complexAmount
- ...
[snip]
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
