>>>>> On Fri, 17 Oct 2014 18:36:01 +0200, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> <tag-name>panelGroup</tag-name>
AT> <component>
AT> <component-type>javax.faces.HtmlPanelGroup</component-type>
AT> <renderer-type>javax.faces.Group</renderer-type>
AT> </component>
[...]
AT> In this case, we know component type javax.faces.HtmlPanelGroup maps
AT> to class javax.faces.component.html.HtmlPanelGroup and the family
AT> should be obtainable via the getFamily() method (which happens to live
AT> in the javax.faces.component.UIPanel base). Here we finally learn that
AT> this family name we're after is "javax.faces.Panel".
AT> Clearly this is quite a hurdle for users and even though the actual
AT> override looks easy in theory, it's thus still difficult in practice.
AT> A few ideas to somewhat simplify this process:
AT> 1. *-types default to class names (where possible, and if applicable)
AT> 2. Extend taglib-xml to contain the family etc data users need
AT> 3. Make the same data discoverable via annotations
AT> 4. Reference things by the fully qualified tag name
AT> 5. Provide APIs to query data like component, renderer, family name,
AT> etc based on fully qualified tag name
This would be a lot of work to implement, for a relatively small amount
of developer value added.
AT> Ad 1
AT> Instead of having component javax.faces.HtmlPanelGroup we could just
AT> have javax.faces.component.html.HtmlPanelGroup as the type string.
AT> This could still be mapped to a totally different class, but by
AT> default (or in absence of any explicit mapping) it would default to a
AT> class with that FQN.
AT> Some types like renderer type javax.faces.Group as used in the example
AT> above maps to an implementation specific class, e.g. to
AT> com.sun.faces.renderkit.html_basic.GroupRenderer in case of Mojarra.
AT> So this would not be a hard rule, just a default.
The decision to keep a layer of indirection between the component-type
and the actual FQCN of the UIComponent subclass was taken way back in
JSF 1.0. We can't possibly change this now.
AT> Ad 2/3
AT> This ties in with some existing issues to enhance the taglib-xml
AT> format and to provide that same data on the artefact itself via
AT> annotations. E.g. JAVASERVERFACES_SPEC_PUBLIC-1193,
AT> JAVASERVERFACES_SPEC_PUBLIC-1190
AT> Ad 4
AT> A fully qualified tag name already embodies to the runtime all
AT> information that's needed, since naturally the runtime uses this to
AT> lookup the actual component, renderer etc. Users quite often think in
AT> terms of this tag name, since it's their main entry point into
AT> component usage. There's already at least one place in the API that
AT> accepts a taglib URI + tag name, namely
AT> ViewDeclarationLanguage#createComponent
Also back in JSF 1.0 was the convention that the tagname was really an
amalgamation of component-type + renderer-type. <h:inputText> means
javax.faces.Input and javax.faces.Text.
Let's restate the use case. You want to make it easier to supply an
alternate renderer for an existing component, right?
For example, when JSF sees <h:inputText> in a page it goes ahead and
creates the HtmlInputText component as usual, but instead of associating
that component with the javax.faces.Text renderer, it uses yours
instead?
Is that the right use case you're after?
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 0 work days til Devoxx 2014