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

[Norbert Truchsess]

What do you mean by 'multiple class implementations'?

If the type is specified in component:interface, there's exactly one
type for this template. And I think it's reasonable to allow multiple
templates for the same component-type, so one can switch the look' feel
without altering the functionality (and so to say the 'interface').

Being able to back a composite-component-template with a custom
component-class would be very beneficial for those building
component-libraries to be used by third parties, because the choice of
implementing a real renderer or just use a template wouldn't influence
the way a component is being used in java. And such component might
completely mask the fact that it's just the root of a whole bunch of
other components.

Picture a form that allows to enter an address - it might provide the
address being entered as an Object of type Address, instead of having
just an attribute-map where you find attributes 'name', 'city' and
'street'. This way you can bind the complex-typed value of a
composite-component directly to your backing bean.

And the user doesn't like the look'n feel he just might override the
template of a given component by specifying the type of this component
in his own template.

- Norbert

Am Samstag, den 01.08.2009, 15:00 +0000 schrieb lincolnbaxter at gmail.com:
> Agreed, I don't see much value in multiple class implementations.
> 
> Sent from my Verizon Wireless BlackBerry
> 
> 
> ______________________________________________________________________
> From: Kito Mann 
> Date: Sat, 1 Aug 2009 10:47:36 -0400
> To: <jsr-314-open at jcp.org>
> Subject: Re: Providing the ability to instantiate
> EzComp components in Java code
> 
> 
> +1
> 
> 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.
> ---
> Kito D. Mann -- Author, JavaServer Faces in Action
> http://twitter.com/kito99  http://twitter.com/jsfcentral
> http://www.virtua.com - JSF/Java EE consulting, training, and
> mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> +1 203-404-4848 x3
> 
> 
> On Fri, Jul 31, 2009 at 5:27 PM, Norbert Truchsess
> <norbert.truchsess at t-online.de> wrote:
>         +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
>         
>         
>