[jsr-314-open] Providing the ability to instantiateEzCompcomponents in Java code

[lincolnbaxter at gmail.com]

Personally I think being able to specify multiple classes for any given template xhtml would be more flexible. 

One potential problem I see when defining multiple java classes is: which class would you use if using markup to build the view?

But if there is benefit in having that info available in the <composite:interface> metadata, then there may be reason to go with that approach.

I think we just need to make sure that its as simple and intuitive as making a composite component: 

1. Attributes need not be implemented in the bound java class. The attribute map should be used if an attribute/getter/setter are not found. 

2. Would it help to provide an abstract class with some built in convenience methods for attributes, potentially also for overriding rendering and such?

3. Also a factory for getting an instance of a non class-bound component is probably in order. The current approach is a bit cloogy.

-lincoln 
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Norbert Truchsess <norbert.truchsess at t-online.de>

Date: Sat, 01 Aug 2009 14:57:56 
To: <lincolnbaxter at gmail.com>; <jsr-314-open at jcp.org>
Subject: Re: [jsr-314-open] Providing the ability to instantiate
 EzCompcomponents in Java code


might work two ways - specify the type in the xhtml (not shure whether
this would best fit in <composite:interface>, <composite:implementation>
or <ui:component>), or declare the namespace+tagname in the implementing
UIComponent class using an annotation.

the first case makes sense if one wants to provide different layouts for
the same UIComponent-type, the second is a better fit, when there's a
one-one relationship of ezcomp and implementing java-class.

- Norbert

Am Freitag, den 31.07.2009, 21:48 +0000 schrieb lincolnbaxter at gmail.com:
> I like it! 
> 
> Perhaps an annotation to specify the namespace?
> Sent from my Verizon Wireless BlackBerry
> 
> -----Original Message-----
> From: Norbert Truchsess <norbert.truchsess at t-online.de>
> 
> Date: Fri, 31 Jul 2009 23:27:18 
> To: <jsr-314-open at jcp.org>
> Subject: Re: [jsr-314-open] Providing the ability to instantiate EzComp
>  components in Java code
> 
> 
> +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 at 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 at 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
>