Gang - On 3/31/10 12:34 PM, Leonardo Uribe wrote: > 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. > I am in favor of re-evaluating cases where we may have been overly aggressive in moving Facelets-related classes/interfaces out of the public API - especially if this is preventing existing frameworks/applications from upgrading to JSF 2.0 in a safe (non-implementation-specific way). Leonardo, Lewis - I would recommend logging a spec issue to track these requirements: https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues Andy

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.

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.

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

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 <mailto:ken.paulsen@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 <mailto:sestechllc@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

+1, which is one thing VAST (missing from JSF2) attempts to help address. Perhaps expanding the pluggable VDL support to include view state support will get us incrementally closer to what VAST was supposed to provide. Although, a new VDL might not be exactly what Gracelets wants as they may just want to augment another VDL (i.e., manipulate the VAST, View Abstract State Tree). Ken On 03/31/2010 02:17 PM, Alexander Smirnov wrote: > I think that Gracelets is going in wrong direction... JSF 2.0 has > pluggable View Description Language API that is supposed for such case. > We already use that for the similar facesFX project ( I hope it will be > on http://www.exadel.org/ soon ). While we found some limitations in the > spec, it is usable and does not require Facelets API at all. > The problems that we faced are like writing and recognizing view state > marker in the different classes, so new VDL requires custom ViewHandler > too. The more significant limitation would be that incremental state > saving belongs to the VDL implementation, so provider has to create its > own from the scratch. > > On 03/31/2010 10:57 AM, Dan Allen wrote: > >> 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&lt;ken.paulsen(a)oracle.com >> <mailto:ken.paulsen@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@gmail.com<mailto:sestechllc@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 >>