Agreed, I don't see much value in multiple class implementations.
Sent from my Verizon Wireless BlackBerry
+1 from my side.
I wander whether we even might go a step further and allow to optionally
assign a 'real' UIComponent-class to an EzComp-Component (one that has
JavaBean getter/setter methods instead of the untyped attribute-map
only).
Then one could do the following in java:
MyFancyUIComponent comp =
(MyFancyUIComponent)Application.createComponent("http://java.sun.com/jsf/composite/myfancynamespace:component");
comp.setMyAttribute(myAttributeTypedObject);
...
Of course when just using the EzComp-component in xhtml the UIComponent
being created by the Facelet would by of the same type.
That would make EzComp-components look indistinguishable from a 'real'
UIComponent in java ;-)
- Norbert
Am Freitag, den 31.07.2009, 11:20 -0400 schrieb Dan Allen:> This is a somewhat old request from Lincoln Baxter that I don't think
> ever made it to the list. After reviewing the message, I too feel it
> is worth discussing for JSF 2.1.
>
> ---------- Forwarded message ----------
> From: Lincoln Baxter, III <lincolnbaxter@gmail.com>
> Date: Thu, Mar 5, 2009 at 10:25 PM
> Subject: Providing the ability to instantiate EzComp components in
> Java code
> To: jsr-314-comments@jcp.org
>
> I feel there is value in the ability to instantiate an EzComp object
> in Java so that a component tree can be built in a backing bean (or
> other Class). JSF must be doing this in the background through
> Facelets, so providing this ability in Java should not be too
> difficult.
>
> Referencing an object by its namespace should be sufficient:
>
> UIComponent comp = Application.createComponent(FacesContext,
> "http://java.sun.com/jsf/composite/mynamespace:component").
>
> Attributes would be assigned via the normal method:
>
> comp.getAttributes().put("rendered", false);
>
> This would greatly extend the reach of EzComp objects.
>
> Thanks,
> Lincoln
>
>
> PS... re-posted here on suggestion of Ryan Lubke