+1<br><br>We should, however, leave the type mechanism in tact (i.e. the current association between a composite component template and a class file should remain the same). I think supporting multiple classes for the same template overly complicates things, and I don't see a common use case.<br clear="all">
---<br>Kito D. Mann -- Author, JavaServer Faces in Action<br><a href="http://twitter.com/kito99">http://twitter.com/kito99</a> <a href="http://twitter.com/jsfcentral">http://twitter.com/jsfcentral</a><br><a href="http://www.virtua.com">http://www.virtua.com</a> - JSF/Java EE consulting, training, and mentoring<br>
<a href="http://www.JSFCentral.com">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info<br>+1 203-404-4848 x3<br>
<br><br><div class="gmail_quote">On Fri, Jul 31, 2009 at 5:27 PM, Norbert Truchsess <span dir="ltr"><<a href="mailto:norbert.truchsess@t-online.de">norbert.truchsess@t-online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+1 from my side.<br>
<br>
I wander whether we even might go a step further and allow to optionally<br>
assign a 'real' UIComponent-class to an EzComp-Component (one that has<br>
JavaBean getter/setter methods instead of the untyped attribute-map<br>
only).<br>
<br>
Then one could do the following in java:<br>
<br>
MyFancyUIComponent comp =<br>
(MyFancyUIComponent)Application.createComponent("<a href="http://java.sun.com/jsf/composite/myfancynamespace:component" target="_blank">http://java.sun.com/jsf/composite/myfancynamespace:component</a>");<br>
<br>
comp.setMyAttribute(myAttributeTypedObject);<br>
<br>
..<br>
<br>
Of course when just using the EzComp-component in xhtml the UIComponent<br>
being created by the Facelet would by of the same type.<br>
<br>
That would make EzComp-components look indistinguishable from a 'real'<br>
UIComponent in java ;-)<br>
<br>
- Norbert<br>
<br>
<br>
Am Freitag, den 31.07.2009, 11:20 -0400 schrieb Dan Allen:<br>
<div><div></div><div class="h5">> This is a somewhat old request from Lincoln Baxter that I don't think<br>
> ever made it to the list. After reviewing the message, I too feel it<br>
> is worth discussing for JSF 2.1.<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Lincoln Baxter, III <<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>><br>
> Date: Thu, Mar 5, 2009 at 10:25 PM<br>
> Subject: Providing the ability to instantiate EzComp components in<br>
> Java code<br>
> To: <a href="mailto:jsr-314-comments@jcp.org">jsr-314-comments@jcp.org</a><br>
><br>
> I feel there is value in the ability to instantiate an EzComp object<br>
> in Java so that a component tree can be built in a backing bean (or<br>
> other Class). JSF must be doing this in the background through<br>
> Facelets, so providing this ability in Java should not be too<br>
> difficult.<br>
><br>
> Referencing an object by its namespace should be sufficient:<br>
><br>
> UIComponent comp = Application.createComponent(FacesContext,<br>
> "<a href="http://java.sun.com/jsf/composite/mynamespace:component" target="_blank">http://java.sun.com/jsf/composite/mynamespace:component</a>").<br>
><br>
> Attributes would be assigned via the normal method:<br>
><br>
> comp.getAttributes().put("rendered", false);<br>
><br>
> This would greatly extend the reach of EzComp objects.<br>
><br>
> Thanks,<br>
> Lincoln<br>
><br>
><br>
> PS... re-posted here on suggestion of Ryan Lubke<br>
<br>
</div></div></blockquote></div><br>