incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coach Wei" <>
Subject RE: [Proposal] RCF - a rich component library for JSF
Date Thu, 05 Apr 2007 02:24:35 GMT
Hi Matthias, 

Thanks for the explanation. 

It looks like highly possible to integrate XAP with RCF/Trinidad. I'll
play with it and see how it goes. 

> -----Original Message-----
> From: [] On Behalf
> Matthias Wessendorf
> Sent: Wednesday, April 04, 2007 3:55 AM
> To:
> Subject: Re: [Proposal] RCF - a rich component library for JSF
> Hello Coach,
> > XAP does Ajax component wrapping on the client side in contrast to
> > jMaki does on the server side. XAP is a 100% client side framework
> > enables developers to write apps using a declarative XML syntax
> > of coding JavaScript. Different from JSF (which does processing on
> > server side), XAP runtime converts such XML into actual Ajax code on
> > client side and maintains state on the client side.
> >
> > More info can be seen at
> >
> > For example, a sample XAP app
> >
> >
> > Do you think XAP and RCF can work together?
> >
> the XAP pages look interesting and the demo is nice as well. I think
> there is a possibility to get them working together. Here is what I
> think might be interesting/worth for looking:
> Since a developer needs to write only a client-side and a server-side
> renderer (see below) for a new (custom) component, there might be a
> way to use XAP and its XAL documents to provide components that fit
> 100% into the client-side lifecycle (see below). Instead of describing
> a complete page with XAL, just provide a XAP/XAL-based client-side
> renderer version for a component. Being able to work inside the
> client-lifecycle would allow a page developer to *reuse* JSF goodies
> like the Validators or Converters and they are still able to work w/in
> the client-side-lifecycle (this isn't that easy when using jmaki,
> afaict).
> At least XAP sounds to be a good way to integrate 3rd party UI
> Toolkits, like Dojo or Rico.
> I saw there is a XAP presentation at the ApacheCon in Amsterdam, I'll
> join your session and take a look at what the speaker has to say about
> XAP. One mailing lists, we can check a technical way to integrate
> them. Not sure how nice this will work, but I think it is worth to
> try. What do you think?
> > Can you elaborate on what you mean by "*rich*" JSF component vs.
> > "*simple*" ajax-jsf-comp? I don't get the differences between jMaki
> > RCF (besides using different tag names and Ajax components). I think
> > they all work similar by converting JSP Tag or JSF tags into Ajax
> > on the server send the Ajax code to run on the client side, and
> > a stateful component model on the server, right? jMaki can wrap a
> > Ajax component not any less than RCF, right? What do you mean by
> > concepts ported to the client"? Is there any architectural
> > between RCF and jMaki?
> jmaki is using some "templating" techniques to enable developers to
> add dojo (or whatever) to their JSF page. The endresult is a generic
> tag, that can be used in several pages. The cool thing is, you can use
> EL to bind values to backing beans and even interact w/ methods of the
> beans. The same is also possible with Facelets. That is a huge step to
> get your own ajax-based "widgets". With "simple" I was trying to make
> clear that here only some templating comes in and in a generic way you
> have a ajax-based tag (not a full-qualified component).
> RCF is a bit different. RCF has a client-side framework and a
> server-side framework. On server-side RCF relies on JSF and the client
> part is also a "portion" of jsf to the client. That means we have
> components available on the client. A JSF component is a JavaBean that
> has some properties and events. The "same" is available on the client,
> as a js class (generated by same metadata RCF uses to generate the
> JavaBeans). Also there is a client-side renderer which is responsible
> for doing all the client side stuff. The server side renderers render
> "basic" HTML (no onclick="doit();" for instance) and at the end of the
> page we use a JSON string to initialize the client side components and
> their properties. The client side renderers join the game do register
> "handlers" for events like click(onclick) or mouse-down (onmousedown)
> for the "raw" HTML. Like for instance you have a slider that has
> somewhere a "+" image-button to move the slider to the right (or left
> in BIDI mode). The image and its <a> element are rendered on the
> server, but the "client handling" is enabled by the client side
> renderer, when it initializes its "root dom element" (the div here):
> <div id="theSlider">
> ...
>   <a id="theSlider:plus"
class="aStyleClassForThePlusButtonOfTheSlider" />
> ...
> </div>
> Not only renderers and components are available on the client. JSF
> concepts like converter or validator as well:
> <inputText id="long" value="#{bean.long}">
>   <validateLongRange min="3" max="12" />
> </inputText>
> When a user enters a string and *tabs* out, a ConverterException (on
> the client with JS) is thrown, since the value is LONG typed, JSF uses
> its default long converter, the JS version is sent down to the client
> and available of the "inputText js component". Let's think about a
> user enters 2 and tabs out. Then the client side framework throws a
> ValidatorException, because 2 isn't inside the expected range.
> When a (client) validator- or converter-exception is thrown, RCF
> creates a client side version of the FacesMessage component and shows
> the user a "error-message". The renderer for the
> JSF-standard-FacesMessage shows/renders a popup-like widget,
> containing the error message.
> (RCF doesn't disable convertion/validation on the server, just because
> there was some client stuff)
> All these concepts work under the "client version" of the lifecycle
> (similar to the jsf lifecycle on the server). So, there is a
> client-version of the JSF-framework, I only gave a short example.
> -Matthias
> >
> > Thanks...
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message