10 Replies Latest reply on May 9, 2007 4:40 PM by dxxvi

    Using Ajax4JSF or ICEFaces

    pmohanan

      Hi...All,

      We are starting a development & are planning to use AJAX & JSF. We have 2 options AJAX4JSF & ICEFaces.

      What should be consider before choosing one of them for the dev purpose.?
      For e.g features - Calendar, Tree menu - are they available now in AJAX4JSF?

      Compatibility - Using ICEFaces are we locked in to the product or using AJAX4JSF allows us to use the ICEFaces tag libraries too...?

      Please do let me know as we are starting the dev. pretty quickly....

      Regards,

      Praveen

        • 1. Re: Using Ajax4JSF or ICEFaces

          Unfortunately, ICEFaces have a closed architecture. Even Ajax4jsf that is designed to be interoperable with third party component library, it cannot help ICEFaces components to become interoperable. If ICEFaces drop down direct-to-dom approach and return back to open world in the future, the combination might be possible.

          • 2. Re: Using Ajax4JSF or ICEFaces
            mrnice

            Definetly use Ajax4JSF and you are free to combine it with whatever you want.

            I first chose ICEfaces, and switched to Ajax4JSF and are pretty happy with it!

            • 3. Re: Using Ajax4JSF or ICEFaces
              pmohanan

              Thanks a lot!!!

              Just another Q. Does Ajax4JSF has all the components like (Tree Menu, Sorting, Pagination, Calendar etc. ) that ICEFaces has?

              Regards,

              P

              • 4. Re: Using Ajax4JSF or ICEFaces

                Ajax4jsf is a Ajax framework. You need to look at RichFaces. RichFaces is Component Library that extends Ajax4jsf:
                http://livedemo.exadel.com/richfaces-demo/

                • 5. Re: Using Ajax4JSF or ICEFaces
                  tedgoddard

                  Typically Ajax component interoperability problems appear in JavaScript, in the browser, rather than on the server during rendering. For instance, some components may use JavaScript to submit themselves to the server directly, bypassing any opportunity to execute and update nearby components.

                  Direct-to-DOM rendering is what allows the developer to focus on their application, rather than low-level Ajax details (such as which component subtree should be rendered in response to which event); of course, we are always interested in improving interoperability with ajax4jsf.

                  ICEfaces is certainly not a closed architecture: it is open source under the MPL and supports a wide variety of third-party components, IDEs, and application servers.

                  • 6. Re: Using Ajax4JSF or ICEFaces

                    Ted, first of all, you are welcome. Glad to hear you in person here.

                    However, "closed architecture" and "open source" are not the same things. If you are fighting against the whole world, open sourcing your weapons does not makes too much sense from the technical perspective. (I am not going to argue about the marketing point of view, of course). BWT, the same will happen with Adobe going to open source Flex under MPL. Closed technology remains closed even the code is open sourced.

                    Closed technology is when you advise that developer "must use **only** standard JSF tags (f:) and ICEfaces tags (ice:)", when you have to decide do you need "to support a trillion component libraries" instead of just leave them working as they are, without any modification.

                    Requirement to replace the original renderers with "Direct-to-DOM" ones is a showstopper for you. It is five-year-old idea. Just drop it and look forward to the future. Using modern browser as a mirror for the server-side object is not only one way how to simplify the development. Together we can find more reliable way how to accomplish it

                    • 7. Re: Using Ajax4JSF or ICEFaces
                      maryka

                      Sergey,

                      You will be less glad to hear from me in person than Ted, as he is far more polite than I. You would do well to abridge the gibbberish that you write to the topics and technologies that you understand. You are doing pmohanan and other forum members a disservice by misrepresenting the ICEfaces technology, and by suggesting that trillions of other JSF component libraries will happily coexist under A4J, because your words and innuendos in both cases are filled with untruths.

                      So, lets start with some facts. As of several releases ago, the ICEfaces framework is fully compliant with the JSF responseWriter mechanism, which means that any well-formed HTML component renderer will function within the framework, and will automatically inherit the features and benefits of D2D rendering. As Ted suggested, most component incompatibilities occur as a result of ajaxifying a component renderer with JavaScript and integrating those Ajax transactions back into the JSF lifecycle. The reality is, that the mechanisms used to achieve this in different libraries may be incompatible. This is an issue that transcends the framework, and you are misleading pmohanan to suggest that under A4J he will not be exposed to this potential risk. Until the JSF community can decide on a common set basic mechanisms for Ajax interactions within the framework, the utopia of trillions of interoperable rich JSF components cannot be achieved, and the development community should be aware of the underlying risks. Some sound advice I heard given at a recent Ajax conference was to select a framework and component suite that delivers most of what you want, and stick with it. With the current state of technology, mixing and matching will expose you to risk, regardless of which framework you pick.

                      While I second that advice, ICEsoft remains committed to improving 3rd party component compatibility within the ICEfaces framework. With the basic responseWriter mechanism in place, our attention has turned to ferreting out JavaScript incompatibilities. The highest priority components for our community are the Tomahawk components, and in our 1.6 release we have made large strides toward dealing with MyFaces JavaScript idiosyncrasies. We have also integrated our Ajax bridge with the OpenAjax hub, so are well-positioned to coexist with other JavaScript libraries that conform to the hub.

                      For those of you out there that are evaluating JSF/Ajax frameworks, I suggest there are other consideration besides component libraries that are important. With ICEfaces, our primary goal is to incorporate Ajax features into JSF in a completely transparent fashion. This means that the Java enterprise developer can develop pure JSF applications and get all the benefits of Ajax without additional development consideration. With A4J you will need to wire all the Ajax interactions together manually, which is an extremely limiting deficiency in the A4J framework. It basically dismantles the separation of roles between developers and designers, and can be extremely debilitating to both. Furthermore, we know Enterprise developers want to work with the tools and development processes that they are used to. We don't cram yet another tool down your throat in order to use ICEfaces. We integrate across all popular IDEs, and fit seamlessly into your existing Java development best practices.

                      Now Sergey, regarding your suggestion that we just drop it, this must be a thought straight out of your dreams. D2D rendering is a 5 year old innovation that we continue to build on, and has resulted in the most transparent means in the industry for Java Enterprise developers to deliver rich interfaces in a pure Java programming model. Since open sourcing, ICEfaces hosts the fastest growing community in the JSF/Ajax realm, and has been established as one of the dominant solutions in the industry. As for cooperation, we are actively engaged with the JSF community to improve the state of the art going forward. I don't get any cooperative vibes coming from your posting. You seem pretty antagonistic to me - again a characteristic that will not benefit the community at large.

                      Finally, I ask that you refrain from misleading the community with inaccurate information about any topic that you are not well-qualified to discuss. Let those of us that understand the ICEfaces technology represent it accurately to the community. None of them are interested in your rhetoric.

                      Steve Maryka
                      CTO, ICEsoft Technologies

                      • 8. Re: Using Ajax4JSF or ICEFaces

                        Steve, thank you for such great response here in forum!

                        Believe me, our goals it the same as ICESoft goals - to provide developers with best technology possible for WEB/Ajax development. So, I'm sure we will help our community if we will make our products works better together and we will help them even more if we will work together on future JSF 2 to make it even better using existing achievements of both of us.

                        So, I ask you to start working together to make both our products better behave with each other. Please contact me directly to ishabalov@exadel.com, so we can initiate some collaboration activity rather sooner than later.

                        Thank you again,
                        Igor Shabalov,
                        CTO, Exadel Inc.

                        • 9. Re: Using Ajax4JSF or ICEFaces
                          pmohanan

                          Hi...Steve & Igor,

                          Thanks a lot for your responses. !! It only makes me believe more stronger to move to open source products (and the company I work completely supports this) .

                          Coming back to the basics, I have only put in the post what I had heard from different people using the products and their reasoning behind choosing a products. ( Which might be completely wrong!! ) But only their experiences help us as a starting point.

                          I will be following this thread more closely & secondly I will also try to give a call to respective companies to get more information.

                          Couple of points I will definitely ask would be:
                          - Component interoperability
                          - Browser dependency
                          - Portal Dependency

                          Is there any thing else missing in the list ??


                          Again, thanks a lot!!

                          Regards,

                          Praveen

                          • 10. Re: Using Ajax4JSF or ICEFaces

                            So, if Ajax4jsf continues going with direct-to-dom and ICEFaces keeps its responseWriter, we'll never be able to use both of them together?

                            I heard that ICEFaces is very buggy, but I received an email about the version 1.6.0 DR #4 with 180+ bugs fixed. So I think it's less buggy now. I wonder if I should spend time on Seam or GWT or ICEFaces: a difficult selection :(