Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of mwessendorf@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=GjPpyNjpdZBVIGNJwaTY87JxDsWMWpQT/DWi8NqU7PinGYhe0KsqPgSUmKpkRM4rNnjnOhBTzRM8O46HH6tSSj5bESzo+rKkjoWngMowCJ6UYgqYRIFSWaQW3KDV/+Ft6AWUU/Nxn+tp5+XaODk5JwKxRSD/qtFJFYoOfe79IPc=
Message-ID: <71235db40704042216q13c0cb89v2b8be67674ab0654@mail.gmail.com>
Date: Thu, 5 Apr 2007 06:16:28 +0100
From: "Matthias Wessendorf" <matzew@apache.org>
Sender: mwessendorf@gmail.com
To: general@incubator.apache.org
Subject: Re: [Proposal] RCF - a rich component library for JSF
In-Reply-To: 
 <DC7475DE75130445B186DBCB617B4A7B0133FFF9@dhost002-43.dex002.intermedia.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46118E91.5050206@oracle.com>
	 <DC7475DE75130445B186DBCB617B4A7B0133FD90@dhost002-43.dex002.intermedia.net>
	 <71235db40704031423w7f761355kb22d7480daabad4a@mail.gmail.com>
	 <DC7475DE75130445B186DBCB617B4A7B0133FE25@dhost002-43.dex002.intermedia.net>
	 <71235db40704040054o1e51585dsbf37954378ce143a@mail.gmail.com>
	 <DC7475DE75130445B186DBCB617B4A7B0133FFF9@dhost002-43.dex002.intermedia.net>

Hey Coach,

sounds cool. You still can cast your vote ;-)

Thx,
Matthias

On 4/5/07, Coach Wei <coach@nexaweb.com> 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: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org