9:02 a.m.
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