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

[Leonardo Uribe]

Hi

The discussion with Lewis on myfaces is here:

https://issues.apache.org/jira/browse/MYFACES-2629

regards,

Leonardo Uribe

2010/3/31 Dan Allen <dan.j.allen at gmail.com>

> 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/16fdfeb2/attachment-0002.html