On 5/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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.
Properly designed components will exhibit "attribute-property
transparency" (like the standard components do), so this might not be
as big an issue as it sounds like. In particular, the following two
calls will have exactly the same effect:
component.setFoo("bar");
component.getAttributes().put("foo", "bar");
Craig
>
> >
> > - 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
