Hey Coach, sounds cool. You still can cast your vote ;-)
Thx, Matthias On 4/5/07, Coach Wei <[EMAIL PROTECTED]> wrote:
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Matthias Wessendorf > Sent: Wednesday, April 04, 2007 3:55 AM > To: general@incubator.apache.org > Subject: Re: [Proposal] RCF - a rich component library for JSF > > Hello Coach, > > > XAP does Ajax component wrapping on the client side in contrast to what > > jMaki does on the server side. XAP is a 100% client side framework that > > enables developers to write apps using a declarative XML syntax instead > > of coding JavaScript. Different from JSF (which does processing on the > > server side), XAP runtime converts such XML into actual Ajax code on the > > client side and maintains state on the client side. > > > > More info can be seen at http://incubator.apache.org/xap > > > > For example, a sample XAP app > > http://www.rockstarapps.com/samples/sendmeapic > > > > 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 and > > RCF (besides using different tag names and Ajax components). I think > > they all work similar by converting JSP Tag or JSF tags into Ajax code > > on the server send the Ajax code to run on the client side, and maintain > > a stateful component model on the server, right? jMaki can wrap a "rich" > > Ajax component not any less than RCF, right? What do you mean by "JSF > > concepts ported to the client"? Is there any architectural differences > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
