You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Coach Wei <co...@nexaweb.com> on 2007/04/03 20:36:35 UTC
Re:[Proposal] RCF - a rich component library for JSF
Hope these questions are not too late with regard to this proposal.
1. The RCF components are fairly well developed and documented already,
which is great, but it also means that there is very limited capacity
for the Apache community to influence and innovate from here. Obviously,
we don't want Apache just to be a hosting place. What are the areas that
you think Apache community can develop and influence RCF in significant
ways going forward?
2. Speaking of Ajax, what's your point of view of XAP and whether/how
does this RCF proposal relate to XAP? Is there any synergy between these
two projects? XAP is a declarative Ajax library for rich internet
applications - all driven by XML and can be easily embedded in
JSP/Servlet/Struts/Shale/JSF pages, which provides similar functionality
as RCF to some degree.
3. Speaking of JSF, jMaki is a fairly well known JSF open source project
(though not Apache). jMaki is open. Instead of reinventing the wheel of
building yet another set of Ajax components, it uses existing Ajax
toolkits such as Dojo, etc. Does RCF use its own Ajax toolkit or uses
some third party Ajax toolkit?
Best regards,
Coach Wei
Nexaweb Technologies
1 Van de Graaff, Burlington MA 01803
o 781.345.5435, f 781.354.5501
cwei@nexaweb.com www.nexaweb.com
Blog: Direct from Web 2.0
> -----Original Message-----
> From: Omar Tazi [mailto:omar.tazi@oracle.com]
> Sent: Monday, April 02, 2007 7:15 PM
> To: general@incubator.apache.org
> Subject: [Vote] RCF proposal (was: [Proposal] RCF - a rich component
> library for JSF)
>
> Hi,
>
> Based on a positive initial feedback we are calling a vote on the RCF
> contribution (see proposal below).
>
> This proposal is for the donation of a rich component library for the
> JavaServer Faces technology to the Apache Software Foundation. The
live
> version of the proposal is available at:
> http://wiki.apache.org/incubator/RCFProposal
>
> A vote was held on the Apache MyFaces dev list and we got 15 +1 votes
> (13 binding) therefore Apache MyFaces is proposed as the sponsoring
> entity/project.
>
> The Champion for the RCF proposal is Manfred Geiler (manolito at
apache
> dot org) and the three mentors are Martin van den Bemt (mvdb at apache
> dot org), Carsten Ziegeler (cziegeler at apache dot org), and Henning
> Schmiedehausen (henning at apache dot org).
>
> Please cast your votes.
>
> Thanks,
>
> Omar Tazi
>
> ---------------------------------
> Omar Tazi
> Chief Open Source Evangelist &
> SOA Evangelist
> Middleware and Tools
> Oracle Corporation
> Work: (650) 506-3216
> Cell: (408) 656-5354
> Email: omar.tazi@oracle.com
> Blog: http://otazi.blogspot.com
>
> =====================================
> RCF, a rich component library for JSF
> =====================================
>
> Abstract
> ----------
>
> RCF is a rich (Ajax-style) component set for the JavaServer Faces(tm)
> 1.2 technology. .
>
> Proposal
> --------
>
> RCF is an Ajax-based component library for the JavaServer Faces
> technology. RCF comes with very high quality components, and skinning
> (CSS-based) capabilities. RCF features include: file upload support,
> client-side conversion and validation, a complete Ajax-integration,
> data tables, hierarchical tables, color/date pickers, menu
> tabs/buttons, wizards, popups, toolbars, toolboxes,
> internationalization and accessibility. This project starts with more
> than 100 components which have already been documented and thoroughly
> tested.
>
> RCF stands for Rich Client Framework and it means that web
> applications, using this component set look very similar to a real,
> native desktop application. The name for this project can be a subject
> to change.
>
> RCF depends on some artifacts, provided by the Apache Trinidad
> project, such as framework features or Apache Maven plug-ins.
>
>
> Background
> ----------
>
> The development of RCF started in 2005 at Oracle Corporation. With the
> advent of Ajax and requirements for highly interactive rich user
> experience, Oracle decided to implement a rich/Ajax-style JSF
> component set. The goal was to advance the already existing ADF Faces
> product, donated to the ASF in early 2006 (Apache Trinidad). When the
> development of RCF started, there wasn't any JSF component set that
> provided similar richness to the user. The RCF components run on any
> JSF 1.2 compliant implementation. RCF is based on some internal
> features of the Apache Trinidad project.
>
> The JavaServer Faces technology is a key technology for the
> RCF component set, since RCF requires JSF as its runtime environment.
> Oracle has a large commitment to both open source and open standards.
> This proposal illustrates Oracle's commitment to the success of the
> JSF standard and supporting the open source community by providing a
> rich component set under a liberal license, the Apache 2.0 license.
>
> Rationale
> ---------
>
> The project is interested in moving to Apache for the following
> reasons: To provide Apache-licensed implementation of a full-blown
> Ajax-based JSF component set, to become better integrated with the
> MyFaces and Shale initiatives, and to build a strong vendor-neutral
> community that will outlast any one person's or company's
> participation.
>
> Initial Goals
> -------------
>
> The initial goals of the proposed project are:
>
> * Viable community around the RCF code base
> * Active relationships and possible cooperation with related
projects
> and communities, such as Apache MyFaces (and its subprojects) or
> Apache Trinidad.
>
> Current Status
> ==============
>
> Meritocracy
> -----------
>
> All the initial committers are familiar with the meritocracy
> principles of Apache, and have already worked on the various source
> code bases. Some of the initial committers also have experience,
> undergoing the Apache incubation process. We will follow the normal
> meritocracy rules also with other potential contributors.
>
> Community
> ---------
>
> The Apache MyFaces project, the Apache Trinidad podling and the
> JavaServer Faces standard hold great promise. A fully Ajax-based set
> of user interface components will significantly accelerate their
> adoption. We strongly believe that RCF will gather significant
> momentum and enough developers to build a vibrant community of users
> and contributors.
>
> Core Developers
> ---------------
>
> Four of the initial committers are Oracle employees and all are
> committers on the Apache Trinidad podling. One of them is a committer
> at Apache MyFaces and Apache Shale. Four of the initial committers are
> committers on the Apache MyFaces project. RCF was developed by Oracle
> employees.
>
> Alignment
> --------
>
> RCF aligns perfectly with Apache MyFaces, Apache Trinidad and other
> ASF projects utilizing J2EE infrastructure such as Tomcat or Shale. Of
> particular relevance are projects such as Geronimo, Apache libraries
> like Jakarta Taglibs and Apache Maven.
>
> Known Risks
> ===========
>
> Orphaned products
> -----------------
>
> Most of the active developers would like to become RCF Committers or
> PMC Members and have long term interest to develop and maintain the
> code.
>
> Inexperience with Open Source
> -----------------------------
>
> All the initial developers have worked on open source before and many
> are committers and PMC members within other Apache projects.
>
> Homogeneous Developers
> ----------------------
>
> Four of the initial committers are Oracle employees. The developers
> are experienced and very familiar with distributed, multi-national,
> asynchronous environments. Also Oracle will most likely influence
> developers across the globe to join the RCF community.
>
> Reliance on Salaried Developers
> -------------------------------
>
> Some of the initial committers are salaried developers employed by
> Oracle. Oracle is committed to standards and open source and committed
> to building a vibrant and diverse community around this project. The
> remaining developers are individual volunteers who are passionate
> about the technology. The donating company has reached out and will
> continue to reach out in its effort to build a diverse community.
>
> Relationships with Other Apache Products
> ----------------------------------------
>
> RCF will likely be used by a Java EE 5 (web) compliant container, like
> Geronimo or Tomcat 6, requires some Apache products (Shale Test,
> commons digester, commons beanutils, Trinidad, Xerces), and will
> support Apache MyFaces.
>
> A Fascination with the Apache Brand
> ----------------------------------------------
>
> All of us are familiar with Apache and we have participated in Apache
> projects as contributors, committers, and PMC members. While we expect
> the Apache brand may help attract more contributors, our interests in
> starting this project is based on the factors mentioned in the
> Rationale section. However, we will be sensitive to inadvertent abuse
> of the Apache brand and will work with the Incubator PMC and the PRC
> to ensure the brand policies are respected.
>
> Documentation
> =============
>
> There isn't a documentation at the moment, but Oracle is actively
> working on developing comprehensive documentation for RCF and that
> documentation will be provided soon or upon availability.
>
> Initial Source
> ==============
>
> The initial code base is owned by Oracle. The applicable code will be
> re-licensed under the Apache License 2.0. All dependencies have Apache
> compatible licenses. These include BSD and CDDL licensed dependencies.
>
> External Dependencies
> =====================
>
> All dependencies have Apache compatible licenses. These include BSD
> and CDDL licensed dependencies.
>
> Required Resources
> ==============
>
> Mailing lists
>
> * rcf-dev@incubator.apache.org
> * rcf-commits@incubator.apache.org
> * rcf-private@incubator.apache.org
>
> Subversion Directory
>
> * https://svn.apache.org/repos/asf/incubator/rfc
>
> Issue Tracking
>
> * JIRA RCF (RCF)
>
> Other Resources
>
> * Wiki
>
> Initial Committers
> ==================
>
> Name Email CLA
> ----------------------------------------------------------------
> Adam Winer awiner at apache dot org yes
> Bernd Bohmann bommel at apache dot org yes
> Bruno Aranda baranda at apache dot org yes
> Cagatay Civici cagatay at apache dot org yes
> Gabrielle Crawford gcrawford at apache dot org yes
> Gary Van Matre gvanmatre at apache dot org yes
> Gerald Muellan gmuellan at apache dot org yes
> Jeanne Waldman jwaldman at apache dot org yes
> Mario Ivankovits
> Martin van den Bemt mvdb at apache dot org yes
> Martin Marinschek mmarinschek at apache dot org yes
> Matthias Wessendorf matzew at apache dot org yes
> Simon Lessard slessard at apache dot org yes
> Werner Punz werpu at apache dot org yes
>
> Affiliations
> ============
>
> Name Affiliation
> -------------------------------------------------
> Adam Winer Oracle Corporation
> Bruno Aranda EMBL-EBI European Bioinformatics Institute
> Gabrielle Crawford Oracle Corporation
> Jeanne Waldman Oracle Corporation
> Matthias Wessendorf Oracle Corporation
> Simon Lessard Fujitsu Consulting, Canada
>
> Sponsors
> ========
>
> Champion
>
> * Manfred Geiler (manolito at apache dot org)
>
> Nominated Mentors
>
> * Martin van den Bemt (mvdb at apache dot org)
> * Carsten Ziegeler (cziegeler at apache dot org)
> * Henning Schmiedehausen (henning at apache dot org)
>
> Sponsoring Entity
>
> * Apache MyFaces
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] RCF - a rich component library for JSF
Posted by Eelco Hillenius <ee...@gmail.com>.
> Instead of reinventing the wheel of
> building yet another set of Ajax components, it uses existing Ajax
> toolkits such as Dojo, etc. Does RCF use its own Ajax toolkit or uses
> some third party Ajax toolkit?
Even though toolkits such as Dojo are high quality and have a broad
feature set, it is not always a bad idea to create widgets from
scratch. Besides the rounder wheel argument, you don't always need all
the genericity such frameworks provide and developing something custom
may enable the component writers to achieve a tighter integration
(which may or may not be a good idea).
My 2c,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] RCF - a rich component library for JSF
Posted by Matthias Wessendorf <ma...@apache.org>.
Hey Coach,
sounds cool. You still can cast your vote ;-)
Thx,
Matthias
On 4/5/07, Coach Wei <co...@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
RE: [Proposal] RCF - a rich component library for JSF
Posted by Coach Wei <co...@nexaweb.com>.
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
Re: [Proposal] RCF - a rich component library for JSF
Posted by Matthias Wessendorf <ma...@apache.org>.
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...
>
>
> --Coach
>
>
> ---------------------------------------------------------------------
> 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
RE: [Proposal] RCF - a rich component library for JSF
Posted by Coach Wei <co...@nexaweb.com>.
Hello Matthias, thanks for the reply.
>
> I am not really familiar w/ XAP. XAP can be used to enable
> JSP/Servlet/Struts/Shale/JSF pages by putting some ajax stuff and a
> "binding" for the components/tags?
> One idea that the community could work on is to add
XAP-Bridge/Support.
>
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?
> > 3. Speaking of JSF, jMaki is a fairly well known JSF open source
project
> > (though not Apache). jMaki is open. Instead of reinventing the wheel
of
> > building yet another set of Ajax components, it uses existing Ajax
> > toolkits such as Dojo, etc. Does RCF use its own Ajax toolkit or
uses
> > some third party Ajax toolkit?
> >
>
> RCF has its own Ajax toolkit. That is because RCF is a *rich* JSF
> component library. RCF has JSF concepts "ported" to the client. Dojo
is
> somewhat generic and can be used to create a "simple" ajax-jsf-comp.
If
> you want to create a full ajax-style JSF-based framework, you'll come
> to the point that this is needed; at least reasonable. (RCF is
> containing components and framework feature). jMaki is a wrapper
> project to simply create JSF components, based on libs like dojo.
> Compared to jmaki, RCF has also "full qualified" jsf components,
instead
> of a
> "ajax-wrapped renderer". I wouldn't call it "reinventing the wheels".
>
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?
Thanks...
--Coach
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] RCF - a rich component library for JSF
Posted by Matthias Wessendorf <ma...@apache.org>.
Hello Coach Wei,
On 4/3/07, Coach Wei <co...@nexaweb.com> wrote:
>
> Hope these questions are not too late with regard to this proposal.
not to late :)
> 1. The RCF components are fairly well developed and documented already,
> which is great, but it also means that there is very limited capacity
> for the Apache community to influence and innovate from here. Obviously,
> we don't want Apache just to be a hosting place. What are the areas that
> you think Apache community can develop and influence RCF in significant
> ways going forward?
At first glance RCF may look mature, agreed. But there are several
areas, where this project could be enhanced. One of them could be
new components. I know that RCF comes with many components, but many
could be added/extended. A charting component using SVG would be a
good candidate. I learned from the Apache Trinidad incubation
experience that every committed user has something special in mind
when it comes to the project's needs.
Another thing is, as mentioned in the proposal we are aiming to build a vendor
neutral community. RCF can be used to create custom "rich" components,
which fit 100% into the JSF-client stuff (see also point 3). In the
best scenario these new components make it into the RCF project as
well, by new committed users (new committers). Extending the framework
is also a possibility. Supporting frameworks like dojo (to name one)
when users need a dojo widget. Isn't it possible to provide a soft
XAP-integration for that? Not that
familiar w/ XAP, but I think it wraps 3rd party (ajax) javascript?
Incubator podling aren't full-blown ASF projects. That is good! So
there is a protection for getting "dead born" communities aboard. Just
let them get their chance to grow inside the Incubator.
> 2. Speaking of Ajax, what's your point of view of XAP and whether/how
> does this RCF proposal relate to XAP? Is there any synergy between these
> two projects? XAP is a declarative Ajax library for rich internet
> applications - all driven by XML and can be easily embedded in
> JSP/Servlet/Struts/Shale/JSF pages, which provides similar functionality
> as RCF to some degree.
I am not really familiar w/ XAP. XAP can be used to enable
JSP/Servlet/Struts/Shale/JSF pages by putting some ajax stuff and a
"binding" for the components/tags?
One idea that the community could work on is to add XAP-Bridge/Support.
> 3. Speaking of JSF, jMaki is a fairly well known JSF open source project
> (though not Apache). jMaki is open. Instead of reinventing the wheel of
> building yet another set of Ajax components, it uses existing Ajax
> toolkits such as Dojo, etc. Does RCF use its own Ajax toolkit or uses
> some third party Ajax toolkit?
>
RCF has its own Ajax toolkit. That is because RCF is a *rich* JSF
component library. RCF has JSF concepts "ported" to the client. Dojo is
somewhat generic and can be used to create a "simple" ajax-jsf-comp. If
you want to create a full ajax-style JSF-based framework, you'll come
to the point that this is needed; at least reasonable. (RCF is
containing components and framework feature). jMaki is a wrapper
project to simply create JSF components, based on libs like dojo.
Compared to jmaki, RCF has also "full qualified" jsf components, instead of a
"ajax-wrapped renderer". I wouldn't call it "reinventing the wheels".
oh, I almost forgot.You can also use facelets instead of jmaki.
BTW. is XAP "close" to jmaki ?
Thx,
Matthias
> Best regards,
>
> Coach Wei
> Nexaweb Technologies
> 1 Van de Graaff, Burlington MA 01803
> o 781.345.5435, f 781.354.5501
> cwei@nexaweb.com www.nexaweb.com
> Blog: Direct from Web 2.0
>
>
> > -----Original Message-----
> > From: Omar Tazi [mailto:omar.tazi@oracle.com]
> > Sent: Monday, April 02, 2007 7:15 PM
> > To: general@incubator.apache.org
> > Subject: [Vote] RCF proposal (was: [Proposal] RCF - a rich component
> > library for JSF)
> >
> > Hi,
> >
> > Based on a positive initial feedback we are calling a vote on the RCF
> > contribution (see proposal below).
> >
> > This proposal is for the donation of a rich component library for the
> > JavaServer Faces technology to the Apache Software Foundation. The
> live
> > version of the proposal is available at:
> > http://wiki.apache.org/incubator/RCFProposal
> >
> > A vote was held on the Apache MyFaces dev list and we got 15 +1 votes
> > (13 binding) therefore Apache MyFaces is proposed as the sponsoring
> > entity/project.
> >
> > The Champion for the RCF proposal is Manfred Geiler (manolito at
> apache
> > dot org) and the three mentors are Martin van den Bemt (mvdb at apache
> > dot org), Carsten Ziegeler (cziegeler at apache dot org), and Henning
> > Schmiedehausen (henning at apache dot org).
> >
> > Please cast your votes.
> >
> > Thanks,
> >
> > Omar Tazi
> >
> > ---------------------------------
> > Omar Tazi
> > Chief Open Source Evangelist &
> > SOA Evangelist
> > Middleware and Tools
> > Oracle Corporation
> > Work: (650) 506-3216
> > Cell: (408) 656-5354
> > Email: omar.tazi@oracle.com
> > Blog: http://otazi.blogspot.com
> >
> > =====================================
> > RCF, a rich component library for JSF
> > =====================================
> >
> > Abstract
> > ----------
> >
> > RCF is a rich (Ajax-style) component set for the JavaServer Faces(tm)
> > 1.2 technology. .
> >
> > Proposal
> > --------
> >
> > RCF is an Ajax-based component library for the JavaServer Faces
> > technology. RCF comes with very high quality components, and skinning
> > (CSS-based) capabilities. RCF features include: file upload support,
> > client-side conversion and validation, a complete Ajax-integration,
> > data tables, hierarchical tables, color/date pickers, menu
> > tabs/buttons, wizards, popups, toolbars, toolboxes,
> > internationalization and accessibility. This project starts with more
> > than 100 components which have already been documented and thoroughly
> > tested.
> >
> > RCF stands for Rich Client Framework and it means that web
> > applications, using this component set look very similar to a real,
> > native desktop application. The name for this project can be a subject
> > to change.
> >
> > RCF depends on some artifacts, provided by the Apache Trinidad
> > project, such as framework features or Apache Maven plug-ins.
> >
> >
> > Background
> > ----------
> >
> > The development of RCF started in 2005 at Oracle Corporation. With the
> > advent of Ajax and requirements for highly interactive rich user
> > experience, Oracle decided to implement a rich/Ajax-style JSF
> > component set. The goal was to advance the already existing ADF Faces
> > product, donated to the ASF in early 2006 (Apache Trinidad). When the
> > development of RCF started, there wasn't any JSF component set that
> > provided similar richness to the user. The RCF components run on any
> > JSF 1.2 compliant implementation. RCF is based on some internal
> > features of the Apache Trinidad project.
> >
> > The JavaServer Faces technology is a key technology for the
> > RCF component set, since RCF requires JSF as its runtime environment.
> > Oracle has a large commitment to both open source and open standards.
> > This proposal illustrates Oracle's commitment to the success of the
> > JSF standard and supporting the open source community by providing a
> > rich component set under a liberal license, the Apache 2.0 license.
> >
> > Rationale
> > ---------
> >
> > The project is interested in moving to Apache for the following
> > reasons: To provide Apache-licensed implementation of a full-blown
> > Ajax-based JSF component set, to become better integrated with the
> > MyFaces and Shale initiatives, and to build a strong vendor-neutral
> > community that will outlast any one person's or company's
> > participation.
> >
> > Initial Goals
> > -------------
> >
> > The initial goals of the proposed project are:
> >
> > * Viable community around the RCF code base
> > * Active relationships and possible cooperation with related
> projects
> > and communities, such as Apache MyFaces (and its subprojects) or
> > Apache Trinidad.
> >
> > Current Status
> > ==============
> >
> > Meritocracy
> > -----------
> >
> > All the initial committers are familiar with the meritocracy
> > principles of Apache, and have already worked on the various source
> > code bases. Some of the initial committers also have experience,
> > undergoing the Apache incubation process. We will follow the normal
> > meritocracy rules also with other potential contributors.
> >
> > Community
> > ---------
> >
> > The Apache MyFaces project, the Apache Trinidad podling and the
> > JavaServer Faces standard hold great promise. A fully Ajax-based set
> > of user interface components will significantly accelerate their
> > adoption. We strongly believe that RCF will gather significant
> > momentum and enough developers to build a vibrant community of users
> > and contributors.
> >
> > Core Developers
> > ---------------
> >
> > Four of the initial committers are Oracle employees and all are
> > committers on the Apache Trinidad podling. One of them is a committer
> > at Apache MyFaces and Apache Shale. Four of the initial committers are
> > committers on the Apache MyFaces project. RCF was developed by Oracle
> > employees.
> >
> > Alignment
> > --------
> >
> > RCF aligns perfectly with Apache MyFaces, Apache Trinidad and other
> > ASF projects utilizing J2EE infrastructure such as Tomcat or Shale. Of
> > particular relevance are projects such as Geronimo, Apache libraries
> > like Jakarta Taglibs and Apache Maven.
> >
> > Known Risks
> > ===========
> >
> > Orphaned products
> > -----------------
> >
> > Most of the active developers would like to become RCF Committers or
> > PMC Members and have long term interest to develop and maintain the
> > code.
> >
> > Inexperience with Open Source
> > -----------------------------
> >
> > All the initial developers have worked on open source before and many
> > are committers and PMC members within other Apache projects.
> >
> > Homogeneous Developers
> > ----------------------
> >
> > Four of the initial committers are Oracle employees. The developers
> > are experienced and very familiar with distributed, multi-national,
> > asynchronous environments. Also Oracle will most likely influence
> > developers across the globe to join the RCF community.
> >
> > Reliance on Salaried Developers
> > -------------------------------
> >
> > Some of the initial committers are salaried developers employed by
> > Oracle. Oracle is committed to standards and open source and committed
> > to building a vibrant and diverse community around this project. The
> > remaining developers are individual volunteers who are passionate
> > about the technology. The donating company has reached out and will
> > continue to reach out in its effort to build a diverse community.
> >
> > Relationships with Other Apache Products
> > ----------------------------------------
> >
> > RCF will likely be used by a Java EE 5 (web) compliant container, like
> > Geronimo or Tomcat 6, requires some Apache products (Shale Test,
> > commons digester, commons beanutils, Trinidad, Xerces), and will
> > support Apache MyFaces.
> >
> > A Fascination with the Apache Brand
> > ----------------------------------------------
> >
> > All of us are familiar with Apache and we have participated in Apache
> > projects as contributors, committers, and PMC members. While we expect
> > the Apache brand may help attract more contributors, our interests in
> > starting this project is based on the factors mentioned in the
> > Rationale section. However, we will be sensitive to inadvertent abuse
> > of the Apache brand and will work with the Incubator PMC and the PRC
> > to ensure the brand policies are respected.
> >
> > Documentation
> > =============
> >
> > There isn't a documentation at the moment, but Oracle is actively
> > working on developing comprehensive documentation for RCF and that
> > documentation will be provided soon or upon availability.
> >
> > Initial Source
> > ==============
> >
> > The initial code base is owned by Oracle. The applicable code will be
> > re-licensed under the Apache License 2.0. All dependencies have Apache
> > compatible licenses. These include BSD and CDDL licensed dependencies.
> >
> > External Dependencies
> > =====================
> >
> > All dependencies have Apache compatible licenses. These include BSD
> > and CDDL licensed dependencies.
> >
> > Required Resources
> > ==============
> >
> > Mailing lists
> >
> > * rcf-dev@incubator.apache.org
> > * rcf-commits@incubator.apache.org
> > * rcf-private@incubator.apache.org
> >
> > Subversion Directory
> >
> > * https://svn.apache.org/repos/asf/incubator/rfc
> >
> > Issue Tracking
> >
> > * JIRA RCF (RCF)
> >
> > Other Resources
> >
> > * Wiki
> >
> > Initial Committers
> > ==================
> >
> > Name Email CLA
> > ----------------------------------------------------------------
> > Adam Winer awiner at apache dot org yes
> > Bernd Bohmann bommel at apache dot org yes
> > Bruno Aranda baranda at apache dot org yes
> > Cagatay Civici cagatay at apache dot org yes
> > Gabrielle Crawford gcrawford at apache dot org yes
> > Gary Van Matre gvanmatre at apache dot org yes
> > Gerald Muellan gmuellan at apache dot org yes
> > Jeanne Waldman jwaldman at apache dot org yes
> > Mario Ivankovits
> > Martin van den Bemt mvdb at apache dot org yes
> > Martin Marinschek mmarinschek at apache dot org yes
> > Matthias Wessendorf matzew at apache dot org yes
> > Simon Lessard slessard at apache dot org yes
> > Werner Punz werpu at apache dot org yes
> >
> > Affiliations
> > ============
> >
> > Name Affiliation
> > -------------------------------------------------
> > Adam Winer Oracle Corporation
> > Bruno Aranda EMBL-EBI European Bioinformatics Institute
> > Gabrielle Crawford Oracle Corporation
> > Jeanne Waldman Oracle Corporation
> > Matthias Wessendorf Oracle Corporation
> > Simon Lessard Fujitsu Consulting, Canada
> >
> > Sponsors
> > ========
> >
> > Champion
> >
> > * Manfred Geiler (manolito at apache dot org)
> >
> > Nominated Mentors
> >
> > * Martin van den Bemt (mvdb at apache dot org)
> > * Carsten Ziegeler (cziegeler at apache dot org)
> > * Henning Schmiedehausen (henning at apache dot org)
> >
> > Sponsoring Entity
> >
> > * Apache MyFaces
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> 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