Manfred,
>> 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.
I agree. The more help the better. I saw a demo of Tapestry a couple of weeks
ago. It sure goes out of its way to communicate all that it can when it comes
to exception handling, probably something we should keep in mind too.
>
>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"/>
This approach would also work. I don't think that anything would stop you from
including a nested clay component too. I like the simple mapping of the
componentType
to a pure JSF component and think that enabling componentType inheritance would
be a
pretty slick solution. Morphing JSF components, it sounds cool. I remember
when
MS Access 95 added Morphing to their IDE designer.
>> 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
> - ...
Your example was cut off. I don't see why these component definitions
can not be grouped and used these ways. A component could be nested within
several other components. The only restriction I see is with
circular associations for both generalization and aggregation relationships.
This restriction has more to do with using recursion to fix-up the inheritance
and build the component tree.
I started a clay test case that extends AbstractViewControllerTestCase. This
guy
has mock JSF classes making it pretty easy to snap togather stand alone junit
tests. I think that this would be a great place to white board the kinds of
issues
that you have outlined without a lot of code - besides all the other benefits
of
automated testing.
I'll upload my starter test in a ticket this week. Hopefully we can get a
committer
to take a look at our outstanding patchs soon. That would make it easier for
us to collaborate going forward :-)
Gary
