> INTRODUCTION
>
> Clay has a simple mechanism for component extending. The component can
> inherit and override the attributes of the "super-components" (analog to
> super-classes). For example,
>
> <component jsfid="inputText" componentType="javax.faces.HtmlInputText"/>
>
> <component jsfid="formInputField" extends="inputText" allowBody="false">
> <attributes>
> <set name="styleClass" value="inputControlStyle" />
> <set name="required" value="true" />
> </attributes>
> </component>
>
> <component jsfid="firstName" extends="formInputField">
> <attributes>
> <set name="value" value="#{managed-bean-name.firstName}"/>
> </attributes>
> </component>
>
> <component jsfid="lastName" extends="formInputField">
> <attributes>
> <set name="required" value="false" />
> <set name="value" value="#{managed-bean-name.lastName}"/>
> </attributes>
> </component>
>
> The html tag is on the top of this hierarchy:
>
> <input type="text" size="20" jsfid="firstName" />
>
> PROBLEMS
>
> ### 1.### The overriding mechanism works partly in case of mapping html
> attributes to result component attributes.
>
> Some of the attributes are passed to the result component, some of them are
> omitted.
> For example,
> <input type="text" jsfid="firstName"
> value="#{managed-bean-name.lastName}" />
> does not work, because value from the html input tag is just omitted. At the
> same time, in case of
> <input type="submit" jsfid="submitForm" value="#{bundle.SubmitName}" />
> the 'value' overrides the 'value' in the submitForm.
>
> ### 2. ### Almost impossible to re-use the existing component from the
> library. The explicitly created component is required. For example,
> instead of just:
> <input type="text" jsfid="inputText"
> value="#{managed-bean-name.lastName}"/>
>
> we have to write in html:
>
> <input type="text" jsfid="firstName" />
>
> and in the clay config file:
>
> <component jsfid="firstName" extends="inputText">
> <attributes>
> <set name="value" value="#{managed-bean-name.firstName}"/>
> </attributes>
> </component>
>
> ### 3. ### Undesirable overriding.
>
> As I mentioned above, in case of
> <input type="submit" jsfid="submitForm" value="Button 1" />
> the 'value' is passed to the component overriding the 'value' in the
> component declaration.
>
> Scenario:
> web designer has created a mockup that contains some buttons and wants to
> keep the title on the buttons as designed for further possible re-design.
> page writer should take the actual title on the buttons from the bundle or
> manage beans properties. However, the declaration:
>
> <component jsfid="submitForm" extends="commandButton">
> <attributes>
> <set name="value" value="#{bundle.SubmitName}" />
> <set name="action" value="whatever" />
> </attributes>
> </component>
>
> does not work without removing 'value' from the html tag.
>
> So, we need a way how to disable overwriting in the particular cases
>
> PROPOSALS
>
> #### 1. ####
> Allow to pass any html attributes to the result component by default
> (excluding jsfid itself and taking carry about problematic html attribute
> names like class, char, for).
>
> All the attribute should allow the JSF EL syntax with
> useValueLateBinding="true" by default. (I suppose, it should be "true" by
> default in general, but it is another story)
>
I like this idea but I think we should combine it with Craig's suggestion in
the earlier thread. Let's provide an object that can be optionally overridden
as a configuration parameter that has the mapping of html elements to component
attributes.
This would mimic the same pattern the DefaultViewControllerMapper uses to
associate a viewId with a registered managed bean ViewController.
> Additionally: It would be nice if JSP 2.0 EL is also supported
>
Not sure what this would entail?
> ### 2. ####
>
> Allow to define new attributes (over the html syntax) and pass them to the
> result component. For example,
> <span jsfId="outputText" value="#{bundle.firstNamePrompt}" />
>
If a component doesn't provide a matching component property it logs it as an
error and assumes it's a component attribute. I think this flexibility would
be nice to have.
> ### 3. ####
>
>
> Introduce the new attribute for tag <set> that names allowOverriding that
> might disable the subsequent overriding. The default value should be true.
> In this case we can resolve the conflict mentioned in the #3# : scenario.
> I.e.
>
+1
Sergey, these all seem like great enhancements. I'm willing to provide the
patches if others are supportive too.
Gary
> html:
>
> <input type="submit" jsfid="submitForm" value="Button 1" />
>
> clay config file:
>
> <component jsfid="submitForm" extends="commandButton">
> <attributes>
> <set name="value" allowOverriding="false"
> value="#{bundle.SubmitName}" />
> <set name="action" value="whatever" />
> </attributes>
> </component>
>
> The same way can be used to omit the particular attribute if it is
> necessary. For example,
>
> html:
>
> <a href="#" jsfid="formLink" />
>
> clay config file:
>
> <component jsfid="formLink" extends="commandLink">
> <attributes>
> <set name="action" value="showData" />
> <set name="href" value="" />
> </attributes>
> </components>
>
>
> This solution is on top of my head. Probably, you guys who know the clay
> code well already keep in mind the better one.
>
> === P.S. Good Stuff =======
>
> Currently, the Clay allows to use the "span" tag as a base for any
> component.
> For example, you can write:
>
> <input type="submit" jsfid="submitForm" value="Button 1" />
>
> or
>
> <span jsfid="submitForm">
> <input type="submit" value="Button 1" />
> </span>
>
> The second approach is a good way to decouple the component from the html
> mockup if it does not fit well the result component.
> I.e. if we do not want to have a lot of allowOverriding="false", we just
> can use the span wrapper and provide own version of the attributes set
>
> --
> Sergey
>
>
>
>
> ---------------------------------------------------------------------
> 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]
