Discussions

News: ICEsoft has open-sourced ICEfaces, their AJAX JSF implementation

  1. ICEsoft has announced that they have released ICEfaces 1.5, their JSF implementation, under the Mozilla Public License. ICEfaces provides the ability to leverage a server process pushing data to a JSF component tree with very little code on the part of the programmer, among other capabilities. From the release notes, version 1.5 introduces a number of changes: in addition to the release under the MPL, the datagrid component's functionality has been enhanced, chart and a positioned panel components have been added, support for several script.acoulo.us effects has been added, and more. The ICEfaces community is based at ICEfaces.org, which hosts downloads of ICEfaces and the IDE integration modules as well as demos, discussions, and documentation. Commercial support for ICEfaces is available from ICEsoft.

    Threaded Messages (47)

  2. Congratulations and thankyou very much for such a useful contribution!
  3. why?[ Go to top ]

    Maybe a bit nasty to say but when i see commercial stuff go OS the first thing i think is that they didn't make it so they dump it. Why is IceFaces suddenly OS, is nobody willing to pay money for it. What is the reason to go OS suddenly?
  4. Re: why?[ Go to top ]

    What is the reason to go OS suddenly?
    We've wanted to make ICEfaces open source for some time, but the key turning point for us now is the opportunity to contribute ICEfaces ideas into the future JSF standard (ICEsoft is now a JCP member). This will take place on two fronts: through the complete open source implementation on ICEfaces.org and more gradually through contributions to DynaFaces and jsf-extensions (https://jsf-extensions.dev.java.net/nonav/mvn/reference-ajax.html). Both of these efforts will make ICEfaces ideas accessible to the JCP in an open form.
  5. Re: why?[ Go to top ]

    What is the reason to go OS suddenly?


    We've wanted to make ICEfaces open source for some time, but the key turning point for us now is the opportunity to contribute ICEfaces ideas into the future JSF standard (ICEsoft is now a JCP member).

    This will take place on two fronts: through the complete open source implementation on ICEfaces.org and more gradually through contributions to DynaFaces and jsf-extensions (https://jsf-extensions.dev.java.net/nonav/mvn/reference-ajax.html). Both of these efforts will make ICEfaces ideas accessible to the JCP in an open form.
    so icefaces will be for jsf what hibernate was for ejb, the teacher. I dont mean that sarcastic, i really hope jsf will get more pragmatic. Escpecially regarding component building.
  6. This sounds good... Does this work with the NetBeans IDE?
  7. Netbeans is supported.[ Go to top ]

    Yes, Netbeans is supported.
  8. NetBeans Supported[ Go to top ]

    Sajit, Yes, NetBeans 5.0 and 5.5 are supported. We also have early access support for Studio Creator 2. We are planning to port our Creator2 Design-time support over to the NetBeans Visual Web stuff soon. You can find the various tool download bundles here: http://www.icefaces.org/downloads/. Regards, Ken
  9. And with Eclipse too ...[ Go to top ]

    in several different flavors: WTP, MyEclipse, and BEA Workshop Studio. Furthermore, work is in progress to improve the ICEfaces-specific visual page construction experience in BEA Workshop.
  10. Can I use Icesoft components through taglibs in my struts 1.3.x project ? Has anyone tried this, is it possible ? Any tips will be much appreciated, thanks, robin
  11. Can't register[ Go to top ]

    This is good new for OSS but I am not able to register to download it. After filling out the register form and selecting register button (NOTHING) don't do squat :((
  12. Can Register[ Go to top ]

    Ignore the last comment its OK now :)) Looking forward to using it...
  13. Re: Can Register[ Go to top ]

    Ignore the last comment its OK now :)) Looking forward to using it...
    This is excellent news, since this component pack also provides integration into the Studio Creator2 / Webpack. (One huge thing missing from most packs)
  14. I think those people writing the obituary for Java are a bit premature.
  15. Damn there is no calendar component in the open source release!
  16. Actually, *all* the components are included in the open source release, including a calendar component. It's called ice:selectInputDate. You can see a demo of most of the components available in the ICEfaces open source release here: http://component-showcase.icefaces.org/. Ken Fyten ICEfaces Product Mgr.
  17. Thank you Ken Fyten for the tip.
  18. And free?[ Go to top ]

    What license? Free to commercial use? if yes, :D
  19. Re: And free?[ Go to top ]

    What license?
    Free to commercial use?

    if yes, :D
    ICEsoft has announced that they have released ICEfaces >1.5, their JSF implementation, under the Mozilla Public >License.
    Mozilla Public License.
  20. It's always good to see contributions like this. Thank you, I'll try it for sure!
  21. Great news for JSF[ Go to top ]

    I wrote up my thoughts on my blog: http://raibledesigns.com/page/rd?entry=icefaces_gets_open_sourced This is great news for JSF. Thanks ICEsoft! Matt
  22. This is great news- especially excited about ICEfaces folks getting involved with DynaFaces- but in terms of using the actual components, is it possible for these to play nice with either Trinidad (formerly Oracle ADF) or Tomahawk components? (I found something in the forums that suggested Tomahawk, at least, was out.) Or do these just interop with the standard JSF tags? I assume they work with both the RI or MyFaces, but what about RI 1.2? I know there's a special renderkit involved ... it seems like as more of these component sets go open-source (ADF, now RCFaces, now ICEfaces), the ability to mix and match becomes important. ICEfaces looks great, but if every time a new set comes out, you have to swap your previous components out whole hog (Trinidad, in my case, and there's a ton of goodies there), it gets real hard to reap the benefits of the platform.
  23. The ability to mix and match becomes important. ICEfaces looks great, but if every time a new set comes out, you have to swap your previous components out whole hog (Trinidad, in my case, and there's a ton of goodies there), it gets real hard to reap the benefits of the platform.
    This is a very good point. Also, I tried the integration with JDeveloper, it is not useful as the JSP designer is not working. One of the JSF productivity issues is to able to design visually. I couldn't understand the benefit of creating an extension like the one they provide for JDeveloper.
  24. I tried the integration with JDeveloper, it is not useful as the JSP designer is not working. One of the JSF productivity issues is to able to design visually. I couldn't understand the benefit of creating an extension like the one they provide for JDeveloper.
    For a complete picture of ICEfaces visual design capability, please check out our JavaStudio Creator tool bundle. Unfortunately, JSF design meta information isn't yet fully portable and the tools have to be tackled one at a time. Please post to the forums on ICEfaces.org to register your interest in support for specific tool chains.
  25. I tested ICESoft earlier but could not integrate it into an enterprise application using other JSF implementations. We had to resort to other vendors to get the level of integration we want. Ideally, one should be able to choose the components one likes from different vendors and integrate them into the same application. For instance, in our application, we are using the Sun implementation of JSF but also using MyFaces tomahawk, QuipuKit and NetAdvantage for JSF components. It is very difficult for one component to satisfy all your needs and if it can not not be easily integrated with other products, it becomes a major usability issue. To be honest with you, I really love some components in ICESoft but the integration problem made us to look else where. To be fair enough to ICESoft, I have not recently tested it, but I have just downloaded the latest version. As soon as I can find the time, I will give it a try once more.
  26. Ideally, one should be able to choose the components one likes from different vendors and integrate them into the same application. For instance, in our application, we are using the Sun implementation of JSF but also using MyFaces tomahawk, QuipuKit and NetAdvantage for JSF components.
    I'm sure the smart folks over at ICEsoft are working on interoperability, but the toolkits will become more cohesive as we standardize the Ajax integration layer in JSF 2.0. You'll see this evolve over time through projects like DynaFaces. Both ICEsoft and Exadel (developers of Ajax4jsf and RichFaces) will be involved in that effort, I believe. --- 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
  27. Re: Integration is an issue with ICESoft[ Go to top ]

    as we standardize the Ajax integration layer in JSF 2.0. You'll see this evolve over time through projects like DynaFaces
    In particular, one of the things that DynaFaces adds is a standard JavaScript method for components to call to initiate a form submit. This will greatly enhance interoperability because it will allow a JavaScript framework (such as the one provided by ICEfaces) to manage the form submission and make it work correctly with other components on the page and with the underlying messaging to the server (such as for Ajax Push).
  28. The ability to mix and match becomes important. ICEfaces looks great, but if every time a new set comes out, you have to swap your previous components out whole hog (Trinidad, in my case, and there's a ton of goodies there), it gets real hard to reap the benefits of the platform.


    This is a very good point.
    Also, I tried the integration with JDeveloper, it is not useful as the JSP designer is not working. One of the JSF productivity issues is to able to design visually. I couldn't understand the benefit of creating an extension like the one they provide for JDeveloper.
    is that a component model is defined but as for now every ide support has to be done separately, there is no common ide interfaces. So it comes down to implement interfaces, binding xmls etc... for every ide separately, even worse for ide versions separately (for instance studio creator uses different binding interfaces than the netbeans 5.5 webpack) so it boils down in most oss libs to have someone who does the bindings or to skip those bindings at all, and rely on generic placeholders in the visual editors, or have the tool providers provide the bindings (which in many cases does not happen) There was a jsr started to resolve this issue, but i do not know how far it is yet. Why that never has been specified in the first place is somewhat beyound me, because one of the selling points of jsf is that you are able to use RAD tools.
  29. Re: Works in JDeveloper[ Go to top ]

    I tried the integration with JDeveloper, it is not useful as the JSP designer is not working.
    Just to clarify, you won't see the component executed and showing up in the JDeveloper WYSIWYG layout editor since they use Javascript and the editor doesn't execute the Javascript. However, you can drag components directly into the structure view window. The structure window is actually a full blown editor. Beside rearranging your components by drag and drop, it also allows you to right click on components and insert more components before/after/inside of them. You can also use the property inspector to set values for the attributes of each component. And of course you get code insight while working in the code editor.
  30. Full JSF 1.2 compatibility is coming soon, but this release contains significant improvements to third-party component compatibility through what we call our "clean DOM" algorithm, however, interoperability between components at the JavaScript level will always be problematic until a standard submit API is defined (such as with DynaFaces). We have not tested with Trinidad or Tomahawk recently, but since the ICEfaces RenderKit converts the standard JSF components into Ajax components, whenever custom components are developed as aggregations of the standard components, they work well and automatically benefit from Ajax.
  31. experiences with DynaFaces[ Go to top ]

    Hi Ted, Great job on IceFaces.org! I was also interested to note that you are considering getting behind DynaFaces and this prompted me to organise some of my notes. So, for those people who want to give DynaFaces a try, I've blogged about my experiences with the early access version at http://www.ninthavenue.com.au/blog/dynafaces Roger
  32. Re: experiences with DynaFaces[ Go to top ]

    So, for those people who want to give DynaFaces a try, I've blogged about my experiences with the early access version at http://www.ninthavenue.com.au/blog/dynafaces

    Roger
    I should also note that Facelets 1.2 is making a revival with Avatar support built in-- but will still continue to work out of the box with all other AJAX extensions. A couple of the issues you did raise were corrected too in the recent 1.2 release of the RI-- around scripting output and evaluation. This affected the 1.2 Dev release of Facelets and it's ability to do 'RJS' events from backing beans instead of requiring custom components/listeners. I'm hoping that as some of these AJAX frameworks get on board with the JSF 1.2 features and really leverage them (in Facelets), we'll see some pretty solid performance improvements, not that all the work Sun's been doing on their RI isn't impressive enough alone :-)
  33. I have been wondering about which web framework to use for my new project for a while. Couldn't decide on Tapestry, JSF. But looking at so many industry supports on JSF, looks like going with JSF is OK. Now if I decide to use JSF, there are now so many choices, both Open Source and Commercial ones: ICEFaces, RCFaces, ... ; Oracle .... Which one to choose ? Any preferences and experiences ? Thanks for you the advices. Chester
  34. If you'd like to take a bigger step[ Go to top ]

    Check out ZK. IMO, it is the simpest way to deliver RIA. Unfortunately, it doesn't support JSF yet.
  35. I have been wondering about which web framework to use for my new project for a while. Couldn't decide on Tapestry, JSF. But looking at so many industry supports on JSF, looks like going with JSF is OK.

    Now if I decide to use JSF, there are now so many choices, both Open Source and Commercial ones: ICEFaces, RCFaces, ... ; Oracle ....

    Which one to choose ? Any preferences and experiences ?

    Thanks for you the advices.

    Chester
    There's actually quite a few more: Infragistics NetAdvantage, Simplica ECruiser, TeamDev QuipuKit, SoftAspects WebGalileo, etc. There's a full listing at http://www.jsfcentral.com/products/. My recommendation is find a single suite that gives you the most mileage, and stick with it... 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
  36. Excellent[ Go to top ]

    Excellent! This is fantastic :-)
  37. JBoss Seam[ Go to top ]

    So, Gavin...I am guessing Seam and ICEFaces integration is coming soon? :-)
  38. yup[ Go to top ]

    Damn straight. We're already discussing this with the ICESoft guys :-)
  39. Does ICEFaces implement fully JSF 1.2 specification and use it in product or it gets Sun RI and changes the render response phase code of the lifecycle?
  40. Does ICEFaces implement fully JSF 1.2 specification and use it in product or it gets Sun RI and changes the render response phase code of the lifecycle?
    As Kito mentioned, ICEfaces is not an implementation of JSF, it adds capabilities to an existing JSF implementation, such as the Sun RI or MyFaces. The Ajax capabilities are added through a custom RenderKit, ViewHandler, and Servlets -- the JSF lifecycle is not changed. JSF 1.2 is not fully supported by ICEfaces 1.5, but will be supported in an upcoming release. (Note that ICEfaces 1.5 with JSF 1.2 is working well with Facelets; an upcoming release of ICEfaces will accommodate the JSP-related changes in JSF 1.2.)
  41. I just wanted to clariy the fact that ICEfaces is _not_ a JSF "implementation". It sits on top of JSF implementations such as the Sun RI and Apache MyFaces. --- 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
  42. Hi, it's really a very good news that ICEfaces becomes OpenSource. It's a serious option for UI render in futures versions of OpenXava framework. I have two questions: 1. Is there some imcompatibility (maybe subtle) for include ICEfaces in a LGPL product. 2. Can an ICEfaces application works as a portlet (JSR-168) application? If yes: Can the ICEfaces controls acquire the style of the container portal? Thanks in advance Javier Paniza
  43. 1. Is there some imcompatibility (maybe subtle) for include ICEfaces in a LGPL product.
    ICEfaces is licensed under the MPL, and it takes advantage of "Multiple Licensed Code" feature of the MPL; in particular, you can chose to license ICEfaces under LGPL V 2.1. So, there should be no problem with including ICEfaces in an LGPL product. http://icefaces.org/main/product/license-faq.iface
    2. Can an ICEfaces application works as a portlet (JSR-168) application? If yes: Can the ICEfaces controls acquire the style of the container portal?
    ICEfaces portlet support is in early access (we will have a short article posted shortly on JSR-168 portlets with JBoss Portal and Apache JetSpeed2). Currently the style of the container is not picked up, but that sounds like an interesting feature. ICEfaces components can dynamically change themes, so the right approach is likely to automatically select a theme name obtained from the container.
  44. ICEfaces portlet support is in early access (we will have a short article posted shortly on JSR-168 portlets with JBoss Portal and Apache JetSpeed2). Currently the style of the container is not picked up, but that sounds like an interesting feature. ICEfaces components can dynamically change themes, so the right approach is likely to automatically select a theme name obtained from the container.
    Very good to hear. I will say that, JBoss Portal allows for theme injection at the page-header-level, so if a specific portlet, using ICEFaces, requires some specific css, it can be injected quite easily. For pure integration in to the container's styles, you'd have to leverage the JSR-168 CSS... which may or may not be of any use. Otherwise, let developers/designers configure their ICEFaces CSS as they wish (but affects portability). STAY METAL! Roy Russo
  45. For pure integration in to the container's styles, you'd have to leverage the JSR-168 CSS...
    Usually portals do a little use of this css, and they are full of propietary css, and use a big amount of HTML + CSS code in order to give style to the portal and its portlets. Therefore, developing portlets that fits well in the style of the portal is not trivial. OpenXava, for example, has a customized style generation class for each portal (currently Jetspeed 2, WebSphere Portal and Liferay). That is, ICEfaces will have to test the style in each portal in order to obtain a good integration. Cheers Javier Paniza
  46. Therefore, developing portlets that fits well in the style of the portal is not trivial. OpenXava, for example, has a customized style generation class for each portal (currently Jetspeed 2, WebSphere Portal and Liferay).
    That is, ICEfaces will have to test the style in each portal in order to obtain a good integration.
    The portlet specification outlines selectors for portlets to leverage, so portlets moved from one portal to another share the same look and feel. Making ICEFaces adopt portal-vendor-specific styles is sheer lunacy. If you leverage the spec, as should be well, in containers that implement it. STAY METAL! Roy Russo
  47. IceFaces & Spring Webflow[ Go to top ]

    Does IceFaces support Spring Webflow ? Is there anybody here who use IceFaces + Facelets + Webflow ? Thanks.
  48. Is this a bug in the distributed dependencies. Specifically myfaces-impl.jar 1.1.4? Installation fails with a ClassCastException while initializing the RepeatRenderer as the context is being started. (Tomcat 5.5.17 ). Kills Tobago webapps on the same Tomcat server. The demos of this product look very nice but the distributed installation failing and the community forum link being down makes getting started "impossible". Hope an easy workaround exists. Thanks. Josh.