BackBase and BEA looking to pair up in Workshop Studio

Discussions

News: BackBase and BEA looking to pair up in Workshop Studio

  1. BackBase and BEA are working to integrate BackBase' AJAX toolkit into BEA Workshop Studio. This is only in proof-of-concept stage, but shows how pervasive AJAX is becoming as a technology. Eclipse is gaining a number of tools in the JSF/AJAX arena. What do you think of this trend?

    Threaded Messages (9)

  2. Eclipse is gaining a number of tools in the JSF/AJAX arena. What do you think of this trend?
    I'd like to see some consolidation soon. Sure, choice and competition is healthy, but at the moment the plethora of frameworks and tools is just bewildering. Choosing one set of frameworks and tools now risks getting stuck with a framework that is not maintained or developed in the future. That being said, I appreciate choice, all I'd like to see is some "dominant players" emerge, in the same sense as Struts and WebWork emerged as dominant forces in the MVC arena in the past.
  3. Ajax is JSF's Killer App...[ Go to top ]

    During one of the Ajax sessions at the recent BEA World conference in San Francisco BEA demonstrated prototype support for the ICEfaces JSF framework as well. It's becoming clear that Ajax support will be a key driver for future JSF adoption. Until now many shops struggled with the cost/benefit equation around adopting JSF just to produce the same types of static web-applications they've been producing all along with Struts. However, using a JSF component set that can provide a seamless, responsive rich user experience based on Ajax-techniques without all the grief and complexity involved in using JavaScript Ajax libraries changes the cost/benefit equation of adopting JSF dramatically. Ajax-enabled JSF components, or preferably complete Ajax JSF solutions such as ICEfaces, are JSF's killer application. It only makes sense for Java IDE tool vendors to want to support market-leading Ajax JSF solutions as it is clearly a large step towards realizing JSF's true potential.
  4. Re: Ajax is JSF's Killer App...[ Go to top ]

    and what JSF brings to Ajax? What if your shops will add Ajax without JSF? Just is order to avoid "cost/benefit equation around adopting JSF". Dmitry Coldbeans
  5. Re: Ajax is JSF's Killer App...[ Go to top ]

    This seems to be my sense as well. As for me, I'd just as soon skip both JSF and AJAX and do it in Swing. For apps that people are in every day, that help run their business, clicking around an event driven web UI just seems overkill, when you look at the security issues involved with JavaScript.
  6. Re: Ajax is JSF's Killer App...[ Go to top ]

    I have been working on Ajax for several years and I believe it is going to creep up in many forms, where Java-swing feels out of place. For example, one place Ajax is better suited than Swing is GIS or interactive maps. For example, please see: http://www.theserverside.com/patterns/thread.tss?thread_id=42349 I am not a security expert, but I feel JavaScript has less security issues than Swing. Also I have been seeing the Ajax is penetrating in the Intranet applications and between trusted providers (e.g. Banks and large corporations), where security is not a big issue. Yahoo maps and charts for Google finance are build using Vector graphics. For example, if one need to place just few interactive Graphics Images on his web page, using Ajax images is simpler than rewriting it in Swing. For example, both Google and MSN are using Vector Graphics in their online maps. I have been noticing, these kinds of feature creep up in many web applications.
  7. Re: Ajax is JSF's Killer App...[ Go to top ]

    Yes, that is a good use case for Ajax.
  8. Do we need JSF for AJAX ?[ Go to top ]

    After experimenting with a number of AJAX enabled frameworks & toolkits, Iam wondering how much value, JSF can add to an AJAX application. Sure, you can do AJAX using JSF and JSF offers a sophisticated 'lifecycle management system' for processing requests. In an Ajax application the Controller is shifted to the browser and an MVC framework like JSF has much limited roll. So it appears to me that JSF unnecessarily adds the complexity of AJAX applications (Iam referring to web 2.0 style full fledged ajax application, not a regular application with a few AJAX enabled components). I found a clientside toolkit like DojoTookit add much more value than JSF(or any other MVC framework). You would still need some framework support at server side to compliment Dojo. Iam looking forward to suggestions on selecting the best suited serverside framework to compliment Dojo toolkit, without adding unnecessary complexity.
  9. Re: Do we need JSF for AJAX ?[ Go to top ]

    Hi Santhosh, JSF is not a replacement for AJAX, but just a way to link a client-side AJAX library to a server-side application. At Backbase we first created a client-side solution (similar to Dojo), and we are now launching server-side components for JSF, Struts and .NET. JSF and AJAX fit well together, because both are based on a component model: JSF has server-side components, and AJAX has client-side components. There are some challenges though: most JSF implementations are multi-page, so every user action triggers a complete page refresh (unlike AJAX). Also, the state between client-side and server-side components needs to be synchronized. In the Backbase JSF Edition we've solved these issues. Because JSF is a standard, you can also use standard IDEs for fast development, such as Eclipse of BEA WorkShop. That's also a big benefit of using AJAX and JSF together. I can't give recommendations for Dojo, but you might want to check out the Dojo website and mailinglist. I remember they do something with the WebWork framework.
  10. BackBase and BEA are working to integrate BackBase' AJAX toolkit into BEA Workshop Studio. This is only in proof-of-concept stage, but shows how pervasive AJAX is becoming as a technology.

    Eclipse is gaining a number of tools in the JSF/AJAX arena. What do you think of this trend?
    On the JSF side of things, I things will really take off once JSR 273 (Design-Time API for JavaBeans) and JSR 276 (Design-Time Metadata for JavaServer Faces Components) are completed. This will enable all of the JSF/AJAX vendors like BackBase to more easily plug into different IDEs (right now it's a lot of extra work for a design-time experience in different IDEs). Kito D. Mann Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info