5:04 a.m.
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(a)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(a)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(a)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/...);
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(a)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(a)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