[jsr-314-open-mirror] [jsr-314-open] Expose TemplateClient api to make gracelets work with jsf 2.0

[Dan Allen]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100331/645a530a/attachment-0002.html