10:20 a.m.
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: [jsr-314-open] 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
10:26 a.m.
New subject: [jsr-314-open] Providing the ability to instantiate EzComp components in Java code
+1
Since one can already create standard JSF components using Java.
Dan Allen wrote:
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
<mailto: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(a)jcp.org <mailto: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
10:44 a.m.
New subject: [jsr-314-open] Providing the ability to instantiate EzComp components in Java code
+1. Sounds like a great idea. Let's capture this in a spec issue if we
haven't already.
Andy
Roger Kitain wrote:
+1
Since one can already create standard JSF components using Java.
Dan Allen wrote:
> 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
> <mailto: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(a)jcp.org <mailto: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
10:45 a.m.
New subject: [jsr-314-open] Providing the ability to instantiateEzComp components in Java code
+1 .....again... ;) I really think this would be a feature nobody else provides, and a LOT
of java component tree building happens at big companies.
Allows total control over the component tree
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Roger Kitain <Roger.Kitain(a)Sun.COM>
Date: Fri, 31 Jul 2009 11:26:37
To: <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] Providing the ability to instantiate
EzComp components in Java code
+1
Since one can already create standard JSF components using Java.
Dan Allen wrote:
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
<mailto: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(a)jcp.org <mailto: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
4:27 p.m.
+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
4:48 p.m.
New subject: [jsr-314-open] Providing the ability to instantiate EzCompcomponents in Java code
I like it!
Perhaps an annotation to specify the namespace?
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Norbert Truchsess <norbert.truchsess(a)t-online.de>
Date: Fri, 31 Jul 2009 23:27:18
To: <jsr-314-open(a)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/...);
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
7:57 a.m.
New subject: [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(a)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(a)t-online.de>
Date: Fri, 31 Jul 2009 23:27:18
To: <jsr-314-open(a)jcp.org>
Subject: Re: 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/...);
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
9:02 a.m.
New subject: [jsr-314-open] Providing the ability to instantiateEzCompcomponents in Java code
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(a)t-online.de>
Date: Sat, 01 Aug 2009 14:57:56
To: <lincolnbaxter(a)gmail.com>; <jsr-314-open(a)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(a)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(a)t-online.de>
Date: Fri, 31 Jul 2009 23:27:18
To: <jsr-314-open(a)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/...);
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
7:14 p.m.
New subject: [jsr-314-open] Providing the ability to instantiateEzCompcomponents in Java code
2. Would it help to provide an abstract class with some built in
convenience methods for attributes, potentially also for overriding
rendering and such?
This is exactly how the RichFaces CDK was designed and, IMO, a very strong
feature.
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
9:47 a.m.
+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/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(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
10 a.m.
New subject: [jsr-314-open] Providing the ability to instantiate EzCompcomponents in Java code
Agreed, I don't see much value in multiple class implementations.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Kito Mann <kito.mann(a)virtua.com>
Date: Sat, 1 Aug 2009 10:47:36
To: <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] 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/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(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
5:04 a.m.
New subject: [jsr-314-open] Providing the ability to instantiate EzCompcomponents in Java code
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
5388
days inactive
5393
days old
jsr-314-open-mirror@lists.jboss.org
11 comments
6 participants
participants (6)
-
Andy Schwartz -
Dan Allen -
Kito Mann -
lincolnbaxter＠gmail.com -
Norbert Truchsess -
Roger Kitain