incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [Proposal] RCF - a rich component library for JSF
Date Fri, 23 Mar 2007 10:26:09 GMT
Hi Noel,


On 3/22/07, Noel J. Bergman <noel@devtech.com> wrote:
> Omar Tazi wrote:
>
> > This is a proposal to donate a rich component library for the JavaServer
> > Faces technology to the Apache Software Foundation.
>
> Please compare, just for our information, with:
>
>  http://myfaces.apache.org/tobago/
>  http://myfaces.apache.org/tomahawk/

Tomahawk:
The first component library, shipped by MyFaces is Tomahawk. That
library is there since *years*. The goal of Tomahawk was/is to improve
the standard jsf components. That means:
a) providing some extras on *standard components*, which they don't
have by default
    <h:inputText> vs. <t:inputText>
    where t:inputText (tomahawk) has some more features, like an
attribute called "autocomplete", just to name only one
b) also the goal is, filling the gab of the standard components and
ship jsf components, that aren't part of the standard. Like "Tree" or
"calendar".

Almost all of these components are styled in a "web1.0" manner. Some
ajax-build stuff is part of the Tomahawk sandbox.

Tobago:
That library made it into MyFaces after it graduated from the Apache
Incubator. Tobago goes a step beyond "traditional" JSF development.
The goal of Tobago is to create apps w/o the need of HTML (inside the
template (jsp / facelet)). In regular JSF dev. it's common to use HTML
inside and *nest* the components inside. The UI components abstract
from HTML. Also Tobago uses a a layout manager (like you know from
Swing) to arrange the components automatically.

Tobago and Tomahawk are both, currently tied to JSF 1.1. Its possible
to mix Tomahawk with other JSF libs, but Tobago can't be used together
with others.

Omar's proposal mentions also the Apache Trinidad podling, currently
undergoing the incubation. Trinidad also provides a set of jsf
components (has some overlap with Tomahawk and Tobago), but Trinidad
can be mixed with Tomahawk and other libs. Trinidad also provides
great "framework feature", like optimized component state saving etc
and also some tools for an easy way of developing JSF components.
Trinidad is available for JSF 1.1 and 1.2. I'd say that Trinidad is
Web 1.5 :) Means looks like Web 1.0, but has some Ajax-like feature to
update parts of the page (using IFrame instead of XHR).


A short comparison with RCF and the other mentioned component sets:

Tomahawk and RCF:
Tomahawk is "Web 1.0" and RCF is "Web 2.0". That is an important
difference. Also RCF contains more components than Tomahawk. Tomahawk
has some components, which aren't available in RCF and vice versa.
Since RCF *reuses* Trinidad feature it also has some advanced stuff
included, like a *CSS skinning* framework, wich aren't available in
Tomahawk. That skinning facility enables you to keep the template (a
JSP or facelet page) untouched, when you want to change the *complete*
look and feel. It's also possible to just change only some area's of
some components via skinning (like an icon for a calendar). Tomahawk
is JSF 1.1 compatible and RCF is designed to work with JSF 1.2.

Tobago and RCF:
Tobago has some components, which aren't available in RCF and vice
versa, but RCF has more components. Tobago also has some framework
feature, which are similar to the Trinidad/RCF framework features.
Tobago is JSF 1.1 compatible and RCF is designed to work with JSF 1.2.

Trinidad and RCF:
RCF is build on top of Trinidad. That basically means, RCF uses the
Trinidad framework-feature and tools. In a nutshell, you can say RCF a
"Rich RenderKit" for Trinidad + a bit more. For instance RCF has more
components than Trinidad. An important difference is also that RCF has
some client site (javascript) stuff. There are client side components
and renderers. Basicly RCF renders plain HTML and when the page is
loaded the client side library joins the game and does some "client
side rendering", when needed (for instance no fancy client side stuff
needed for an <outputText>, but for a slider it is).

Also, here is a captured demo, of the RCF components, used in a demo-shop:
http://www.oracle.com/technology/products/jdev/viewlets/1013/richclient_viewlet_swf.html

Future of Tomahawk (perhaps off topic to this list, but was already
addressed inside the Apache MyFaces community):

To make Tomahawk working with JSF 1.2, we are discussing to relay on
Trinidad's tools and framework feature. Tomahawk2 will be rewritten
and during that a "clean up" is also part of the rewriting-plan.
Basically to address questions like "why 3 tree or 2 tables".


> > Based on a quick Google and a USPTO search there doesn't seem to be
> > anything that would cause trouble with the "RCF" name.
>
> Er, what about Eclipse RCF?  Rich Client Framework.  But this relates to the
> question I asked above: do we need a separate project and name for multiple
> sets of Faces components?  Are we keeping them separate, or eventually just
> having a box of parts?

Personally I don't think we need a separate faces components project.
But (the more I think about it) a separated project, containing JSF
component sets has its charm. A "JSF Components project" could be the
goal where the best of all worlds should be collected. That "faces
components" project could be compared with JSTL, which also has a
"family" of taglibs instead of a large one.

I think we need to discuss that in the MyFaces community.

If you have more questions, please ask me on this list.

-Matthias

>
>         --- Noel
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message