Hi,
On Monday, November 10, 2014, Edward Burns <edward.burns_at_oracle.com> wrote:
> >>>>> On Fri, 17 Oct 2014 18:36:01 +0200, arjan tijms <
> arjan.tijms_at_gmail.com> said:
> 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.
Perhaps, although not everything on the list has to be done, or maybe even
nothing. They're just ideas to kick off the discussion.
There's perhaps something to say for the fact that 80% of the work is in
the last 20% of the job. I know getting lots of small details right
often takes a disproportionate amount of time, but when they are right the
product gets a very elegant and polished feel.
That said, I know there are many issues that can be addressed for 2.3 and
resources are limited of course.
> 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.
I'm definitely not asking to change it. A naming convention (for the
component-type name of new components) with optionally a default would not
change the core indirection layer, would it?
It's as with navigation rules. The decision that action outcomes would be
identifiers in rules stems from JSF 1.0 as well. Still, JSF 2.0 was able to
introduce some defaults: if there's no rule matching a certain outcome, the
outcome represents a view id.
Perhaps it's possible to see if we can do something like this for
component-types as well.
> 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?
Yes. It's basically the use case Manfred has been blogging about, but then
just easier to do for the user. If it's only for a single instance of the
tag (like in Manfred's blog post) then this is okay too. To repeat the
important bits here:
<h:panelGroup>
<f:attribute name="rendererType" value="MyRenderer"/>
</h:panelGroup>
"[And then make sure you set it to the right componentFamily]"
The problematic part is thus "set it to the right componentFamily", since
users can't easily get hold of that bit of information.
In general the larger use case is of better customization of existing
components. After state troubles and creating components, this is possibly
one of the most complained about issues in JSF. It comes up in basically
every discussion, see e.g.
http://java.dzone.com/articles/why-you-should-avoid-jsf?page=1#comment-122907
"I think JSF specification should have specified guidelines/rules for JSF
widget developers to expose a template or some form of a method to
customise the rendered output (html) by the widget user."
That request seems to go a bit further than just replacing the renderer,
but I think it's a similar use case.
Kind regards,
Arjan Tijms