Discussions

News: RCFaces : New Open Source Ajax JSF Library Released

  1. RC Faces or Rich Client Faces is a JavaServerFaces library that provides a component set for building next generation Web applications. RC Faces use AJAX technologies and an object-oriented JavaScript API to build highly dynamic pages. You can see an example of the RC Faces component library from the RC Faces Showcase page, including tabs, sortable datagrids, menus, input fields, trees, calendars, and more. A quick description of features:
    • Client API symmetrical to the server API (every property is read/write on both sides)
    • Documented (javadoc, tlddoc & jsdoc)
    • Open Source : LGPL
    • Use AJAX without knowing AJAX
    • Very good perceived load time
    • Very customizable (css and renderkit)
    • Client Live Debug console
    • Supports IE > 6.0 and Firefox > 1.5
    • XML-RPC framework
    • Client side entry validation framework
    • On the work : specific IDE based on Eclipse / WTP
    Message was edited by: joeo@enigmastation.com

    Threaded Messages (26)

  2. Looks good[ Go to top ]

    seems sleek . Is tree component shown in demo - be loaded lazily i.e loading children lazily when clicked on parent node ? Thanks Mittal
  3. Re: Looks good[ Go to top ]

    Looks very good indeed!
  4. Re: Looks good[ Go to top ]

    Is tree component shown in demo - be loaded lazily i.e loading children lazily when clicked on parent node ?
    The level of preloading is configurable. That's the way AJAX tree control should be done!
  5. It is great to have more and more JSF libraries supporting Ajax. It like the widgets and I certainly like the fact that the library is well documented. However, I think it's a pity that we get better and better JavaScript components/libaries, but instead of "wrapping" them into JSF components, to often the same components are developed again, just to make them fit into JSF. Are the underlying JavaScript components written for this project or are existing libraries like Dojo, Yahoo UI Libary or similiar being used? http://developer.yahoo.com/yui/ http://www.dojotoolkit.org/ I know that these libraries/developers don't like Java to much, but maybe it's time to "embrace and extend". Stephan Albers
  6. Re: JavaScript library/components[ Go to top ]

    I know that these libraries/developers don't like Java to much, but maybe it's time to "embrace and extend".
    I think is not! You need to integrate JS controls with JSF component and life-cycle models too. If you want JSF wrapers around well-known JS controls look at: jMaki project: https://ajax.dev.java.net/ Judging from the speed, consistency of UI and user experience of the demo, RC faces are better.
  7. Re: JavaScript library/components[ Go to top ]

    I know that these libraries/developers don't like Java to much, but maybe it's time to "embrace and extend".

    I think is not! You need to integrate JS controls with JSF component and life-cycle models too.

    If you want JSF wrapers around well-known JS controls look at: jMaki project: https://ajax.dev.java.net/

    Judging from the speed, consistency of UI and user experience of the demo, RC faces are better.
    I was not aware of jMaki and I will have a look at that. I am not questioning that the controls need to be integrated with the JSF life-cycle and that some changes might be needed for that, but do we need to write completely new components or can we change/extend what is already there? If I look at the Yahoo UI controls and some of the work from Jack Slocum http://jackslocum.com/yui/, then I would love to see that thightly integrated with JSF. Developing a bunch of controls in Javascript that has a nice feature set, works seamless in most browser, is well documented, performs well, and is lean enough for public websites is a lot of work and it would be great if that could be reused for JSF.
  8. Re: JavaScript library/components[ Go to top ]

    If I look at the Yahoo UI controls and some of the work from Jack Slocum http://jackslocum.com/yui/, then I would love to see that thightly integrated with JSF.

    Developing a bunch of controls in Javascript that has a nice feature set, works seamless in most browser, is well documented, performs well, and is lean enough for public websites is a lot of work and it would be great if that could be reused for JSF.
    I actually think Jason Lee is working on that in conjunction with Sun's RI on Java.net-- some of the details are still being worked out, but he does have some stuff demo'ed privately.
  9. Re: JavaScript library/components[ Go to top ]

    I actually think Jason Lee is working on that in conjunction with Sun's RI on Java.net-- some of the details are still being worked out, but he does have some stuff demo'ed privately.
    I am. I have the calendar and menu wrapped up and functional, but not yet "perfect." I have a couple of guys who are itching to help (one's going to tackle the tree controls). So far, they're coming together nicely. And I definitely have an eye on Jack's stuff. I'm with Jacob. He's doing some amazing work, and I'd love to see some easy integration with JSF. Hopefully, I (with some help) will be able to help us move in that direction. Once we work out some issues with regard to the RI and all that, I hope to have a public demo of them. Jason Lee, SCJP JSF RI Dev Team
  10. Those components aren't "JSF wrapped" AJAX components. They have been designed from the ground up to integrate AJAX and JSF. Each component exists on both sides (client and server) and the APIs (java and javascript) manipulating them are symetrical. The components are synchronized by delta (only differences travel over the request) between client and server to limit the bandwidth usage. The javascript library doesn't use any other project. it evolved from 3 and a half year of work and several major IT projects.
  11. Impressive[ Go to top ]

    I am one of the guys who works on the Tomahawk components, and I must say this stuff is very impressive. Kudos to you guys, you pulled off something really amazing here.
  12. Re: Impressive[ Go to top ]

    I am one of the guys who works on the Tomahawk components, and I must say this stuff is very impressive.
    Kudos to you guys, you pulled off something really amazing here.
    I realize this is off-topic but since you're here, can you tell us why there are multiple My Faces extension libraries ? I understand Trinadad comes from the Oracle donation but why Tomahawk and Tabago ?
  13. Re: Impressive[ Go to top ]

    I am one of the guys who works on the Tomahawk components, and I must say this stuff is very impressive.
    Kudos to you guys, you pulled off something really amazing here.


    I realize this is off-topic but since you're here, can you tell us why there are multiple My Faces extension libraries ? I understand Trinadad comes from the Oracle donation but why Tomahawk and Tabago ?
    Well that is somewhat easy to explain. Tomahawk is the original extended component lib which was started by the original myfaces guys. The Tobago guys already had an extented component lib when they joined the myfaces project and the Trinidad (former ADF donation) lib basically is coming from the oracle side. I joined the myfaces project about two years ago, and as far as I know the codebase, the tomahawk lib is somewhat loosely coupled with components going into various directions, while the Togabo lib is highly integrated. (my job is currently to merge dojo in as time permits, so we do not go the integrated framework route but more along the encapsuled compoent route with a thin framework layer as we need it) The ultimate goal is to make all this libs work together vice versa, while in the latest trunk this works pretty well already for the Tomahawk and Trinidad components it is somewhat problematic with the Tobago lib because it uses its own layting mechanism utilizing a custom view handler. Due to this fact there is a lot of different functionality which is pretty much the same all over three component sets. (For instance we have at least three datatables, two different partial page renderers, once scope tag and one which is simpler to handle but rather limited (savestate) and additonally to that the Trinidad dialog framework. if you take all three component libs into account a lot of functionality is duplicated, mainly due to historical reasons, not because most people wanted to reinvent the wheel. (basically all three libs were developed parallely with different aims)
  14. Re: Impressive[ Go to top ]

    It's really impressive! The first time I see JSF component suite demo that looks as fast, responsive, consistent, good-looking as GWT applications. This tells there is nothing wrong with JSF itself, but there is a tremendous amount of work needed to have any web component suite really useful (JS/DHTML deep programming, browser inconsistencies, performance problems, state synchronization problems with AJAX...). Could you imagine how much work was invested in GWT for example. RCFaces authors are developing/evolving their suite for years.
  15. I agree that the demos look promising. I'm wondering how well it will work with other component sets that have AJAX or partial refresh capability like ADF Faces/Trinidad? Has anyone tried them in that type of environment?
  16. I agree that the demos look promising. I'm wondering how well it will work with other component sets that have AJAX or partial refresh capability like ADF Faces/Trinidad? Has anyone tried them in that type of environment?
    Agree regerding partial-page update. Sun DynaFaces goes in that direction. For a JSF component suite to be truly usable, there are following requirements: - client side component model in JS (RCFaces does that) - support for conversations (ADF Faces/Trinidad has process scope) in order to correctly handle multiple windows/back button/hard URLs - support for partial page updates (ADF faces/Trinidad and DynaFaces has this) - support for efficient skinning - support for efficient choosing/configuring whether some events will be handled on server or client, like tree node expanding, tab sheet selecting, grid sorting/paging... No JSF component suite has it all yet.
  17. - support for conversations (ADF Faces/Trinidad has process scope) in order to correctly handle multiple windows/back button/hard URLs
    Can you be more explicit about that ?
    - support for partial page updates (ADF faces/Trinidad and DynaFaces has this)
    RCFaces has it too ;-) check out the Address Book Demo at http://www.rcfaces.org/abd/ The login/account creation page is working this way. RCFaces uses it for tab views too.
    - support for efficient skinning
    The components' look is dependent on CSS and for specific UI the renderkit system allows every modifications. There is no proper skin manager though. That could be an idea ...
    - support for efficient choosing/configuring whether some events will be handled on server or client, like tree node expanding, tab sheet selecting, grid sorting/paging...
    That's what RCFaces is based on ! Each event can be executed on the client or on the server or both depending on the calling syntax : On the client Side (JavaScript) : On the Server Side (Java) : On both Sides : Javascript then eventually Java (if allowed by the Javascript code)
  18. - support for conversations (ADF Faces/Trinidad has process scope) in order to correctly handle multiple windows/back button/hard URLs

    Can you be more explicit about that ?
    You need conversational scope that is somewhere between request and session scope in order to build truly rich and stateful web UIs. Conversational scope is tied to one browser window and spans multiple HTTP requests (either AJAX or page refreshes) but not the whole HTTP session (several pages to complete a user oriented transaction. You somehow specify the boundaries of conversations, for example with a set of pages. When flow control stays whithin that set of pages, you stays in the same conversation. For example, you enter a page with read-only presentation of a complex entity, like financial instrument. Then you press edit button to start editing it. Then you navigate to new window to edit some instrument details. Then you come back to original window that edits instrument. Then you edit instrument causing several round-trips to the server. Then you press save button and instrument is saved. This is an example of conversation. Seam has support for conversations, but I think it is tied to JPA.
  19. but I think it is tied to JPA.
    No, you can use Hibernate, JDBC, or whatever API you want. On the other hand, Seam can provide deep integration between JPA (or plain Hibernate) and JSF with persistence context and identity guarantees scoped to the conversation. This is especially attractive for AJAX rendering, where you want the guarantee that during one conversation, a particular database row is only present once in-memory. The Seam transaction assembly for JPA (or plain Hibernate) also allows components to pull data from domain model objects on-demand (lazy loading) during a conversation.
  20. I think it hasn't anything to do with JSF component state... JSF state is (I think) bound to the backing bean, so it uses the same context as the backing bean use. If your backing bean is a Session Bean and it is marked as conversational, the JSF component tied to it should be stateful in the same context as the backing bean... ┬┐Am I wrong? If I'm wrong I see a clear problem with JSF components being aware of the state's lifecycle. They should be able to store the state but not be aware of how much that state will last.
  21. There shouldn't be any problem there. But the team hasn't tested that yet.
  22. RCFaces and IDE[ Go to top ]

    It's possible use RCFaces with one IDE like JDeveloper or Sun Studio Creator?
  23. Re: RCFaces and IDE[ Go to top ]

    Using RCFaces with an IDE such as RAD 6, Exadel, JDevelopper or Sun Studio Creator is possible. Those IDEs use a template system to get a graphic rendering for a specific library. The templates don't exist yet so there's some work to be done there. To my knowledge, there is no specification yet for managing the relations between IDEs and JSF libraries. The team is working on a plugin set to be installed over Eclipse WTP. This tool will allow preview and wysiwyg edition of jsf pages (without an application server). The main difference between this and the other IDEs is that the components will be rendered as they would be in "real life". This should be available in january 2007.
  24. Use AJAX without knowing AJAX
  25. +1 We recently had a discussion about web frameworks at my company. We are supporting 50 different web applications in our Websphere environment. For the past 3 years, we've been using Struts 1.x and/or a Struts-like homegrown framework. We decided to pick a new web framework on our next project. I suggested that we should choose a web framework with native Ajax capabilities. Ruby on Rails was proposed but we were concerned that there wasn't a good way for a Ruby web application to invoke our company's internal Java libraries. (We know about JRuby but did not feel it was ready to be used in our enterprise) In the Java camp, we discussed the Echo2 framework, WebWork/Struts2, and Wicket. We felt that a component-based web framework would be best. We choose Wicket. Wicket has native Ajax support + a nice programming model for creating web components. We built a simple prototype with Wicket and we are happy so far. We've decided to continue using Wicket on the current project. Wicket is currently in the Apache incubator: http://incubator.apache.org/projects/wicket
  26. It's funny- this article showed up on TSS right in the middle of a serious flirtation I was having with Perl's Catalyst. Right now I use JSF in two places: a webapp at work which does rich (JSF + Trinidad PPR + JFreeChart) internal reporting, and a hobby fantasy baseball webapp at home which I hope to launch soon. In both cases I have full control over the tech choices. Now, never in a million years would I abandon JSF for the work app--I enjoy food and shelter, no way am I giving up enterprise Java professionally--but for the hobby site, I was seriously thinking of migrating to Catalyst, even though my data model is already up and running in Hibernate et. al. The newest Facelets distro was giving me headaches; DynaFaces seemed brittle; Shale annotations bombed out with JSF 1.2; my own attempts to wrap YUI or Jack Slocum YUI-ext widgets felt way too hard, all those and Shale remoting hoops and DynaFaces bugs killing me ... I was just having this "Is it worth it?" moment, after my twentieth peeling back of the FacesServlet onion in the Eclipse debugger. (side note: my wife asked me at one point in the hair-pulling-out: "Do you think you might be adopting this technology too early?" My answer: "Oh, I'm *definitely* adopting too early." The work webapp, obviously, stays a distro or two behind the hobby app.) It felt like cheating, but I started researching Catalyst. (no RoR for me, those rails don't bend enough) I looked at Mason, which allows very quick, flexible component development; at the lightweight MVC architecture which I felt I could realistically plug into (custom Lifecycles, phaseListeners spook me); and DBIC in the ORM layer, not quite Hibernate but awfully sharp. I started thinking about what my hobby app would look like in that world, and it almost felt refreshing- I would get back control over my URLs, I could easily swap in a Mason-wrapped Jack Slocum grid for my current Trinidad PPR datatable (increasing my wow factor considerably) and generally mix 'n' match the latest Ajax gizmos to my heart's content with a minimum of pain ... sure I'd lose effortless validation and have to do a little plumbing to bind up my model, but Perl's CPAN has a gazillion modules to help. Then I came across this. I have no idea if these components will "drop in" for me (Facelets + JSF RI 1.2 + Trinidad- at the very least, I'll have to roll my own facelets-taglib), but it was a much needed reminder of the promise of JSF. There's nothing in CPAN that touches this- I don't think it's even possible, Catalyst + Mason is too loose for people to build stuff like this, in such a way that others can use immediately. I took a fresh look at JSF and decided to give FreeMarker-based custom component development a shot. Surely, I decided, overcoming ResponseWriter is an easier task than giving up my precious Hibernate and prebuilt tabbed panels and ridiculously easy PPR through Trinidad and whatever other amazing components you amazing big companies are going to give away for free (!) in the coming year(s). What was I thinking?! So anyway, congrats to the RCFaces team on some very impressive work.
  27. Documentation[ Go to top ]

    When can we expect full documentation? I'm anxious to start using it, and have; however, I haven't had any success. I downloaded the example, copied a portion of it that I'd like to use, and tried to customize it.
  28. Re: Documentation[ Go to top ]

    Hi, We have a good bit of documentation now ! You can find on www.rcfaces.org : - a description of each component - a TLDDoc - a javadoc for the components and on www.sourceforge.net/projects/rcfaces - code source for the demo and sample - code snippets that show particular use of the library we're still working at : - completing the javadoc - completing the javascriptdoc Fred