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

Alexander Smirnov asmirnov at exadel.com
Wed Mar 31 17:42:20 EDT 2010 

Sorry for the inconvinience, as I took a look for Gracelets code I found
that they use VDL as well. Thought I did not investigate so deep into
their code to understand why is it need access to the Facelets API at
all ( do they mix groovy/xml on the same page ? ), from my point of view
it should be complete different solution that uses language advantage.
For example, OOP inheritance looks much more powerful then XML-based
templates.
Once again, I suppose for efforts to make VDL really extensible instead
of exposing implementation details.

On 03/31/2010 02:28 PM, Ken Paulsen wrote:
> +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<ken.paulsen at oracle.com
>>> <mailto: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<mailto: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
>>>

More information about the jsr-314-open-mirror mailing list