free for deployment of commercial applications built using the community edition of ICEFaces?That is correct, you can freely develop and deploy using the ICEfaces Community Edition. If you wish to make use of clustering and advanced asynchronous HTTP handling in a large-scale application, we expect you will want to move up to the Enterprise Edition.
Great! Under what license would it be available or which of these would the license most closely look like : BSD, Apache, LGPL, GPL If its available under one of the more lenient license's, I would definitely be taking a closer look at ICEFaces. The feature list is impressive and it does indeed have the professional touch to it.free for deployment of commercial applications built using the community edition of ICEFaces?
That is correct, you can freely develop and deploy using the ICEfaces Community Edition. If you wish to make use of clustering and advanced asynchronous HTTP handling in a large-scale application, we expect you will want to move up to the Enterprise Edition.
Great! Under what license would it be available or which of these would the license most closely look like : BSD, Apache, LGPL, GPLThe license is a commercial license, rather than an open source license (at this time). Essentially, you may use the binaries for development and deployment, but you may not reverse-engineer ICEfaces and you may not sell the ICEfaces SDK standalone.
If its available under one of the more lenient license's, I would definitely be taking a closer look at ICEFaces. The feature list is impressive and it does indeed have the professional touch to it.
Does it support the use of Facelets instead of JSP ? I know in the past there were some issues with it in the past.Facelets are supported in this release of ICEfaces. Facelets give you a number of powerful re-use techniques for assembling web interfaces, so we definitely recommend their use with ICEfaces.
I thought Ajax stands for Asynchronous JavaScript and XML but all ajax request from this "framework" are synchronous. C'mon, it just freezes the whole browser until the request is done. Tell me this is a bad joke.Actually that's not at all true, thankfully. ICEfaces uses an asynchronous AJAX bridge to invoke DOM updates. No nasty ' whole browser freezes' necessary.
I'm sure it does. But not in this demo [http://demo.icesoft.com/component-showcase/]. The nasty 'whole browser freezes' thing is there. period. Maybe on other browser it configures itself to use async connection, but I tested it with FF1.5.0.3 and IE6 and both were freezing during requests.I thought Ajax stands for Asynchronous JavaScript and XML but all ajax request from this "framework" are synchronous. C'mon, it just freezes the whole browser until the request is done. Tell me this is a bad joke.
Actually that's not at all true, thankfully. ICEfaces uses an asynchronous AJAX bridge to invoke DOM updates. No nasty ' whole browser freezes' necessary.
Maybe on other browser it configures itself to use async connection, but I tested it with FF1.5.0.3 and IE6 and both were freezing during requests.ICEfaces does use asynchronous requests, but, as you have correctly observed, also makes use of a synchronous request in some cases: application-initiated page updates are sent asynchronously (hence the capability to develop "COMET" applications) but user events were sent synchronously. Typically the user event request returns immediately with no data and the page update request is used to update the page (even when initiated by the user). We were making use of the synchronous XMLHttpRequest to ensure event ordering at the server and see very good results with it in our internal testing (partly because the response returns no data; yes, we are well aware of the "evil" nature of the synchronous mode of XMLHttpRequest but, since no data was being returned, thought server latency would be low and it would be an acceptable mechanism to ensure message ordering). However, high latency network conditions are a different matter, and the synchronous request will freeze the browser no matter how quickly the server responds (even with no data). We plan to update our demo servers with an all asynchronous XMLHttpRequest configuration later today. In a follow-on release we will enhance the ICEfaces messaging layer so that message ordering is guaranteed without making use of synchronous requests (and the guarantee may itself be configurable, as it's not needed for all applications).
Then what is the purpose of this Servlet in the web.xml of the Tutorials ?The blocking servlet is indeed used with asynchronous XMLHttpRequest. ICEfaces makes use of two servlets, the PersistentFacesServlet, which is just like FacesServlet, but kicks off a "persistent" session (one from which the server can initiate updates independent of user events) and the BlockingServlet (a servlet that makes use of "blocking" HTTP connections to deliver updates asynchronously to the browser). A blocking HTTP connection does not return a response immediately, it returns a response only when data is available. This has the effect of turning HTTP into a messaging protocol that allows the server to send messages to the client. Of course, it makes sense only with the asynchronous mode of XMLHttpRequest.
com.icesoft.faces.webapp.xmlhttp.BlockingServlet
I thought Ajax stands for Asynchronous JavaScript and XML but all ajax request from this "framework" are synchronous. C'mon, it just freezes the whole browser until the request is done. Tell me this is a bad joke.Well, I've been running things as a test locally, and they're not blocking the browser at all. What makes you think it's synchronous?
I know a synchronous request when I see one :) Looking at window.connection, the online demo really _is_ using synchronous requests. Which is evil. And feels terrible. However, looking at the javascript code it should be possible to configure it to use asynchronous requests. The question remains though, why do they use synchronous request by default?I thought Ajax stands for Asynchronous JavaScript and XML but all ajax request from this "framework" are synchronous. C'mon, it just freezes the whole browser until the request is done. Tell me this is a bad joke.Well, I've been running things as a test locally, and they're not blocking the browser at all. What makes you think it's synchronous?
What's your value proposition when it comes to ECHO2? I see that you're JSF compliant, but besides that...ICEfaces is entirely based on the standard API provided by JSF, as you point out. This is extremely important in terms of developing an application with ICEfaces -- the bulk of what you need to know can be found in books in every bookstore and thousands of other resources. Developing asynchronous applications with ICEfaces is particularly easy: all that the developer needs to do is identify what triggers in the application should result in the page being updated, they do not need to determine what those updates should be or what individual components are involved. ICEfaces does the hard work of determining the minimal update and applying it to the page whenever so initiated by the application. This frees the developer to focus on the application rather than low-level details. ICEfaces exposes a number of interesting user-interface features through the simple, declarative programming model of JSF. For instance, draggable and droppable panels relay their state to the application through action events. In the action event handler, the application can obtain a bound Java object associated with the draggable, and in this way work with Drag and Drop directly in terms of application objects.
Is there any IDE support for these components? Hopefully there is, but I'm afraid I know the answer already. I realize its not that hard to add components with markup but its pretty astounding to me that there's no standard that lets component developers provide visual support across the many different JSF tools. Its my understanding that this standard is in the works but its the most glaring oversight in my opinion.ICEfaces components can be used in the JavaStudio Creator visual designer (support for this is in early access), and we will progressively add IDE support for ICEfaces over time (for instance the Eclipse WTP JSF design-time capabilities look very interesting). Is this the answer you were afraid of? The standardization of JSF components themselves is very good, but the way that different component sets hook into different IDEs is not standard, so each IDE does require a certain amount of special treatment.
ICEfaces components can be used in the JavaStudio Creator visual designer (support for this is in early access), and we will progressively add IDE support for ICEfaces over time (for instance the Eclipse WTP JSF design-time capabilities look very interesting).That's good to know.The standardization of JSF components themselves is very good, but the way that different component sets hook into different IDEs is not standard, so each IDE does require a certain amount of special treatment.Yes. That was the point I was trying to convey. Why is there no standard? One of JSF's purposes was to allow novice developers to create drag 'n' drop apps with ease. For the most part, you can do this only if you use the components that ship with that particular IDE. A standard set of designer APIs would ease the burden on the component developer and make a larger portion of components accessible to users.
If you all are interested in an alternative to icefaces take at look at the demo I have created.That's a nice combo-box component; since you described it as an "alternative" to ICEfaces, though, I must point out that it's not browser-portable (it doesn't work in Safari). The approach of adding individual Ajax components to an application is problematic because the question then becomes how to update one component when the state of another changes. You've picked a city from the combo box, but how does your address label get updated? In the JavaOne presentation "Evolving JavaServer Faces: Ajax Done Right" Ed Burns described this problem as JSF components being confined to "swim lanes". With ICEfaces we've solved this problem by putting the entire page under Ajax control; when the application state changes, the page is rendered and the minimal updates are applied to any component on the page, not just the component involved in the UI event. This preserves MVC because all the coupling between components is through the data model. Whenever components are coupled to each other in the view, separation between the model and the view is lost (and the declarative programming model of JSF is eroded as well).
Here is the link:
http://developer.ebusiness-apps.com:8888/EbaJsfComboBox/
how to update one component when the state of another changesThe combobox is a successful integration of Ajax and JSF because it keeps things simple. The solution I choose was to let the difference technologies each do what they do best. Ajax is great for helping the user with the autocomplete UI pattern. JSF is great for rendering and processing HTML form posts. In my demo the HTTP Form Post processing and JSF data model state management is solely controlled by plain old JSF. In many situation a small amount of Ajax can make a big improvement in a web applications’ user interface. The Asynch Ajax request provides a compelling UI improvement but does not change the state of the JSF backing beans. The JSF model’s state and the state of other components in JSF View is only updated when the HTTP Form is submitted and a HTTP postback the JSF framework occurs. In my demo, the country ComboBox controls the “Province” ComboBox with small amount of JavaScript. This coupling is totally outside the JSF framework. A clear advantage to this approach is interoperability with other JSF components and extensions. A limit to this approach is that update to state requires a non-ajax postback. For now I am happy with this limitation. Beyond the ComboBox I am looking more complete JSF Ajax components like the EBA’s Grid. Currently I am not sure about the best approach and I will be keeping an eye out for post like this. Does IceSoft have a strategy in place for AJAX framework interoperability?
Does IceSoft have a strategy in place for AJAX framework interoperability?To start with, we provide the API for developing Direct-to-DOM components, and they're very easily ported from existing stream-based components. The most feasible approach is not to write Ajax components at all -- Ajax components should be assembled from a complete set of primitives that hide the necessary JavaScript. For instance, Facelets allows you to define a custom component from a fragment of markup and expression bindings. Components defined in this way and using the standard JSF HTML components automatically become Ajax components under ICEfaces. On a larger scale, the first step to Ajax interoperability is to standardize on the messaging layer. For purely user-driven Ajax components this isn't so important, but for frameworks (like ICEfaces) that provide application-initiated page updates (also called "COMET", "Reverse-Ajax", or "push") the asynchronous message channel must be shared, so the Ajax components must agree on how to use it. This also means integration at the server, so standardization here will be tricky. One important area of standardization will be for the Java Servlet API to accommodate blocking HTTP requests (HTTP requests for which the response is delayed by the server in order to deliver a message at the right time).
