Now is the perfect time for me to finally pass on this message from the
Gracelets author (perhaps Leonardo has a parallel thread going with him).
I asked Lewis:
"Let us know what you need in JSF 2 to make this work better for you and we
will treat Gracelets as a case study in our discussions about the Facelets
API."
Here is his reply from October:
I think up front after analyzing again the JSF 2.0 API, what would help
integration alot is having the TagLibrary as part of the public API.
Allowing at least discovery, use and manipulation of the Tag Libraries that
are currently loaded. Without this it is a pain, and integration will
require a per-JSF 2.0 implementation specific library to accompany and/or be
distributed with Gracelets and any other third party library that wants to
participate in the library process without having to sacrifice what the user
currently has at his disposal.
I then received an e-mail from him last week:
Well, I have an alpha 1 release, am about to do an alpha 2 release and will
soon be posting information about Gracelets + JSF 2.0, but just
wanted to
give you a heads up. Since I have not heard back from you about the
TagLibrary issue, for the moment an integration library will have to be
downloaded/shipped with Gracelets in order to be used with each different
JSF implementation, at the moment SUN RI and MyFaces.
The fact that he needs different integrations library is definitely a sign
we need to reevaluate where the classes fall.
-Dan
On Wed, Mar 31, 2010 at 1:04 PM, Ken Paulsen <ken.paulsen(a)oracle.com> wrote:
I believe the intent was to provide a View meta-data API (VAST - View
Abstract State Tree) which abstracted this level of detail w/o tying it to
Facelets. That way frameworks such as Gracelets could write to that API and
work w/ any View technology (not just Facelets). Therefor, making the
Facelets-specific API's part of the implementation makes sense.
Not sure where things stand right now, though...
Ken
On 03/31/2010 09:34 AM, Leonardo Uribe wrote:
Hi
This message is on behalf of Lewis Gass.
I am writing in relation to a particular use case which reveals that the
current JSF 2.0 public API is defficient. This is in relation the open
source project Gracelets (
http://gracelets.sourceforge.net/) and the new
effort to integrate JSF 2.0 with Groovy. In order for people to use Groovy
as an alternative View Langauge they need
to have access to the all the Facelets tag libraries and participate in the
Templating framework that Facelets provides. Much of this is tied to the
TagLibrary and
TemplateClient API's. Before, with JSF 1.2, there was a single Facelets
"API" and/or implementation. So integrating with it was much simpler, as is
shown by previous Gracelets
versions. With JSF 2.0, part of the Facelets library was divided into
public
API and another as JSF 2.0 specific implementation.
However, basic concepts such as Templating (TemplateClient and
TemplateManager) are not considered public API, which means that a
technology such as Gracelets
must rely on a per JSF implementation integration library which is volatile
in nature. The FaceletContext class is public API, but implementations are
not required to support
third party implementations of such, and there is no standard way to access
the TagLibrary used by facelets so that third part View Languages can
harness them.
Thus this message has the purpose of requesting such parts of the old
Facelets library, namely, the TagLibrary, TemplateClient and the related
FaceletContext methods (popClient(),
pushClient(), extendClient() and applyDefinition()) to be part of the
public
JSF 2.0 API, while at the same time requiring JSF 2.0 implementors to
support third party implementations
of the same classes/API's.
Respectfully,
Lewis Gass
Gracelets Coder
sestechllc(a)gmail.com
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen