Friday, 16 May 2008

Building Collaborative CRUD Applications With ICEfaces and NetBeans

CRUD-style applications remain the mainstay of enterprise application development, but more and more, application developers are looking to add Rich Internet Application (RIA) capabilities into their development process. ICEfaces provides a comprehensive development framework for building RIAs using pure Java techniques based on JavaServer Faces (JSF), but beyond RIA features ICEfaces can truly revolutionize web applications by facilitating real time collaboration using Ajax Push. The latest ICEfaces 1.7 release includes complete integration with NetBeans 6.0.1 making it easy to build collaborative RIA-style applications, and Glassfish combined with the Asynchronous Request Processing (ARP) features of Grizzly provides the scalable deployment infrastructure required for push-style web applications. Note: NetBeans 6.1 integration is underway and will be available soon...

That is the intro to an article that was recently published at netbeans.org. You can read the full article here. You can find the code for the example at our tutorial page under the IDE Tutorials. More on this subject when the NetBeans 6.1 integrations is complete.

Technorati Tags:

Posted by steve.maryka at 3:22 PM in Entries by Steve Maryka

Responses (0)

Thursday, 24 April 2008

ICEfaces at JavaOne 2008


JavaOne 2008 is shaping up to be an excellent show. In particular, you should be sure to pre-register for Asynchronous Ajax for Revolutionary Web Applications on Wednesday at 9:30 AM. Jeanfrancois and I have distilled the key ideas behind Ajax Push/Comet so that you can understand the Asynchronous Web Revolution. We will even describe how the Resin API works (even better than the explanation we gave at AjaxWorld).

If you would like to have your copy of Ajax in Practice signed, stop by the JavaOne DigitalGuru on Tuesday at 2:30 PM. There's even a chance to win a reproduction of the nice hat the lady on the cover is wearing (ok, I'm joking about the hat, but I will be there to talk about Ajax and ICEfaces).

At the ICEfaces booth, we will have a full contingent of people ready to answer your questions about ICEfaces (from core framework to components) and to give you a chance to provide your comments and influence the project roadmap. It's always possible on the forums, of course, but often its easier to explain your ideas in person. Most importantly, you can pick up this year's ICEfaces T-shirt and enter our iPod Touch giveaway.

This year there are a number of interesting sessions relating to Ajax Push; here are a few that I've found (titles are abbreviated in some cases):

  • TS-5250: Asynchronous Ajax for Revolutionary Web Applications : Wed 9:30
  • TS-6482: Ajax and JavaServer™ Faces Technology: Wed 2:50
  • BOF-5661: Comet: The Rise of Interactive Web: Wed 6:30
  • BOF-4922: Using Google Web Tookit and Comet: Wed 7:30
  • BOF-6584: Using Comet to Create a Web Game: Wed 8:30
  • TS-5415: Java™ Servlet 3.0 API: Thu 10:50
  • BOF-5495: Untangling the Asynchronous Web: Thu 8:30
  • TS-4883: Java™ NIO Technology w/ Grizzly Framework: Fri 1:30

Technorati Tags:

Posted by ted.goddard at 6:45 PM in Entries by Ted Goddard

Responses (0)

Wednesday, 23 April 2008

Ajax Pushed at fisl9.0


fisl9.0 turned out to be a far greater success than I could have imagined. With over 7000 participants and a few (beneficial) schedule changes, I had a chance to present with Alexandre Gomes (standing room only; be sure to check out his BOF on GWT at JavaOne), Francois Orsini and Gregg Spoar.

Here I am, showing WebMC on the iPhone. The trick to giving web-based demos on the iPhone (when the server is on your laptop and a WiFi network may or may not be available) is to enable connection sharing on your Mac (even if you don't have a connection to share). This works much better than creating an ad-hoc network from the Airport menu. You can even use multicast DNS names from the iPhone, such as "icefaces.local".

Technorati Tags:

Posted by ted.goddard at 6:07 PM in Entries by Ted Goddard

Responses (0)

Monday, 21 April 2008

What ever happened to ICEfaces EPS?

From time-to-time there is a forum post or other inquiry asking about the ICEfaces Enterprise Production Suite (EPS) and how it relates to the open-source ICEfaces project. A fair amount of confusion has been caused by the migration of the EPS features from a commercial product offering into the open-source ICEfaces project. To clear that up I though a quick history of the EPS product may be useful.

Just to make it absolutely clear right off the top, while the EPS started life as a commercial product offering, since July, 2007 (ICEfaces 1.6) the major features that constituted the EPS have been freely available under the open-source MPL license.

ICEfaces 1.0 (May, 2006) was released under the ICEfaces Community License, which was absolutely free to use and deploy, but was not open-source. This remained true for all versions prior to the inaugural open-source release of ICEfaces 1.5 in November of 2006. So all ICEfaces versions prior to 1.5 were Community License, and all versions 1.5 and greater have been under the open-source Mozilla Public License (MPL).

In addition to the free Community Edition of ICEfaces there was also an Enterprise Production Suite (EPS) product that had to be commercially licensed and used in conjunction with the free-to-use ICEfaces 1.0 and 1.1 libraries. The EPS added the following additional capabilities to the standard ICEfaces product:

  • - More sophisticated asynchronous connection management and recovery, including the ice:outputConnectionStatus component.
  • - Support for deploying ICEfaces asynchronous apps. in a cluster, incl. detailed configuration instructions, etc.
  • - Improved asynchronous resource utilization and scalability via the stand-alone ICEfaces Asynchronous HTTP Server (AHS).
  • - A Broadcast Render Manager API that added the ability to easily broadcast asynchronous updates across application sessions on different nodes in a cluster, or across different applications.

When ICEfaces 1.5 was released under an open-source license in Nov. of 2007, it was still possible to license the EPS under a commercial license and use it with ICEfaces 1.5.

Beginning with the ICEfaces 1.6 release in July of 2007, EPS as a commercial product was withdrawn and most of the key features that were originally provided in the EPS edition were added into the core ICEfaces code-base under the open-source license, including the enhanced asynchronous connection management features and support for clustered deployments. The Asynchronous HTTP Server (AHS) was offered as a separate project on ICEfaces.org, also under MPL open-source license.

As of ICEfaces 1.7 (April, 2008) the AHS server has been moved into the core ICEfaces project as it has become a key component in the ICEfaces portlet configuration. The stand-alone ICEfaces AHS project is now dormant as future work will be done on the AHS facility that is part of the core ICEfaces repository.

The Broadcast Renderer is the one remaining element of the original EPS product that has not yet shown up in the open-source ICEfaces product. However, plans are in place to add this capability for ICEfaces 1.7.1.

In summary:

  • - The Enterprise Production Suite (EPS) was a commercially licensed product that worked with ICEfaces 1.0 - 1.5 to offer enhanced robustness, performance, and scalability for large-scale asynchronous deployments.
  • - With ICEfaces 1.6 (July 4th, 2007), the commercial EPS product was withdrawn from the market and the key features it provided were contributed to the open-source ICEfaces project.
  • - As of ICEfaces 1.7.1 (Est. May, 2008), the last missing EPS feature, the Broadcast Render Manager, will be added to the core ICEfaces libraries.
I hope this helps clear up any confusion that may have been caused by the gradual migration of the EPS features into ICEfaces proper over the last few releases. The good news is that those features that once constituted a commercial product offering have all been contributed into the open-source ICEfaces project, further strengthening ICEfaces' support for large scale asynchronous deployments.

Technorati Tags:

Posted by ken.fyten at 11:12 AM in Entries by Ken Fyten

Responses (0)

Monday, 14 April 2008

ICEfaces 1.7 - Something for Everyone

ICEfaces 1.7 is here!

A lot of sweat and a few tears went into it, and it took a little longer to arrive than many of us would have liked, but I think you'll be very pleased with how it turned out. The culmination of over 45 enhancements, 110 improvements, and 300 bug fixes, there's no question that it's a major leap forward in the evolution of ICEfaces.  With significant enhancements and improvements in every direction you look, there is truly something here for everyone.

Perhaps the most visible changes are the 7 entirely new components (e.g. context menu, rich text editor, media player, Google map, split-pane, etc.), with an additional 6 subcomponents for Google Maps alone. Additionally, there have been a whopping 47 component enhancements made as well, including user-resizable table columns, multi-column / multi-row table headers, row-span grouping of table data, auto-positioning for popup panels - the list goes on and on. An entirely new theme has been added too, called "Rime", which provides a fresh new face for the  ICEfaces Component Suite.  I'm pleased to report that in this release we've been able to address most of the highest-ranked new component features as voted for by the ICEfaces community.

To better demonstrate all the new component features the Component Showcase sample applications have been completely redeveloped. The new Component Showcase features improved code-samples, more consistent styling and layout, and improved component demos for many components. It also provides additional links to component documentation and resources, tutorials, etc., providing an excellent starting point for anyone looking to learn more about the components. 

Less visible, but equally important to everyone leveraging ICEfaces' asynchronous update features (Ajax-push) in wide-scale deployments is the addition of out-of-the-box support for 5 leading Asynchronous Request Processing (ARP) implementations, such as Glassfish "Grizzly" and Tomcat 6 / JBoss 4.2 NIO. By leveraging these ARP implementations ICEfaces applications can  immediately benefit from reduced server-side resource consumption for asynchronous applications, resulting in increased scalability of asynchronous apps. on the same hardware and software. Special thanks to Jean-Francois Arcand at Sun for all his help with the Glassfish Grizzly integration.

In addition, we've re-engineered the JavaScript bridge to handle asynchronous connection management between multiple viewports using a robust connection sharing implementation that eliminates issues related to using multiple async. views between browsers and to the same host due to the HTTP 2-connection limit. The Asynchronous HTTP Server (AHS) has also been added into the core ICEfaces bundle for this release, along with a new servlet deployment mode that makes it easier to configure and use.

The changes above were a key enabler for ICEfaces much improved support for JSR-168 portlets, including full support for multiple ICEfaces portlets on a the same page, async. or synchronous, from a single .war file or several. ICEfaces 1.7 has been verified with 5 leading Java portal containers, including Liferay Portal, BEA WebLogic Portal, and JBoss Portal. Some really outstanding work has been done to bring robust portlet support to the ICEfaces community. I'd like to give a shout-out of thanks to our friends at Liferay in particular, who have been fantastic supporters of ICEfaces and continue to work with us to bring the best portlet development experience possible to the combined ICEfaces and Liferay communities.

New features are nice but without excellent documentation and examples they can be difficult to use effectively. On this front we've put a concerted effort in to review and upgrade the ICEfaces documentation in this release, beyond simply refreshing references, etc. for 1.7.  The net result is we've added of 8 entirely new sections and 2 new appendices. We've really tried to fill in some gaps in the and react to community suggestions for improvements. I'd strongly recommend to everyone to check out the new docs, it will save you time in the long run and allow to get the most out of what ICEfaces has to offer.

There really is far too much that's new and improved in 1.7 for me to cover here, updates to Tool integrations, new Seam sample applications, etc., etc..  Check out the Release Notes for the complete picture.

Finally, I'd need to highlight how greatly 1.7 has benefited from all the community involvement along the way. A special thank-you to everyone who's been working with the ICEfaces 1.7 early-access releases and reporting issues, offering suggestions, and making contributions. It's been a very challenging, yet satisfying release, and that's best kind, really. 

Technorati Tags:

Posted by ken.fyten at 12:23 PM in Entries by Ken Fyten

Responses (0)

Thursday, 10 April 2008

Ajax Push Comes of Age

Ajax Push has always been an integral capability of the ICEfaces framework, but for the longest time it was not a primary consideration of the average technology evaluator. We always found this surprising, because the impact that push can have on a web application is far more profound than Ajax's primary claim to fame - eliminating the full page refresh. In recent months, however, we have seen a marked change in demand for push technology within the ICEfaces community, and we are now involved with a large number of projects where Ajax Push is front and center on the requirements list. So when people are evaluating their options for achieving web-based push, what makes them decide on ICEfaces?

Simply put - ICEfaces provides the most comprehensive open source solution in the industry for lightweight (plugin-free), push for web applications. Now, I will back up that statement with the supporting facts.

To begin with, while there are hundreds of open source Ajax libraries out there, only a small handful offer push capabilities - namely Dojo/Cometd, DWR/Reverse Ajax, and ICEfaces/Ajax Push. All three mechanisms are based on the same fundamental concept of HTTP protocol inversion - holding an open request from the browser, and responding to that request when something is available to be pushed. Normal and inverted HTTP connections are illustrated in the figure below.

Normal HTTP Connection

So if all push mechanisms are based on this low-level protocol inversion, then how can they be fundamentally different from the developer's perspective? With ICEfaces we have strived to provide a natural extension to the JSF programming model in support of push style application development, and have sheltered the developer from the low-level mechanics for Ajax-based push. ICEfaces provides an application-level managed bean, the RenderHub, that orchestrates push events within the JSF lifecycle. Basically, you define groups of client sessions that need to receive the same push events, and register those render groups with the hub. Some trigger point in application logic can then request a render on a given render group, and the hub will make it all happen. The hub is responsible for executing the render phase for each session in the group, coalescing requests and maximizing throughput with multiple parallel render threads. Furthermore, the RenderHub architecture supports clustered deployments. This basic push architecture is illustrated below.

ICEfaces Push Architecture

From the developer's perspective, it is a clean, natural mechanism for implementing push logic using pure Java programming techniques. What is less obvious (and rightly so) are some of the intricacies that the underlying push mechanism handles. The first relates to the browser and connection limits for the same URL. One connection from the browser is required for the push channel, and a second is required to handle user initiated requests, so an application requires 2 connections, which happens to be the maximum allowable in Internet Explorer. The connection usage for a single view onto the application is illustrated in the leftmost schematic in the diagram below.

Now if you attempt to open multiple views onto the same web application you will not have sufficient connections to support it, as each view needs a connection to support its push channel. With ICEfaces, the push mechanism in the Ajax Bridge provides connection sharing that allows multiple views to share a single connection for push updates. It is based on shared cookies where a single view marshals updates for all views, and if the controlling view is closed, another view takes over. The connection sharing for multiple views support is illustrated in the center schematic in the diagram below.

The connection problem is amplified in a portal deployment where you might have multiple portlets from different web applications looking to share the same push connection. In this case, not only do you need connection sharing at the browser, but also at the server. And because the server side connection management needs to communicate with multiple web applications you need some IPC mechanism to support it. With ICEfaces we have adapted the Asynchronous HTTP Server to handle connection management for portlets. The portal deployment support is illustrated in the rightmost schematic in the diagram below.

Normal HTTP Connection

Now if we turn our attention fully to the server-side connection issues related to push we see scalability concerns with multiple open connections at the Servlet level. Each connection requires a dedicated threat to handle it, so thread exhaustion can occur quickly within the application server. Efforts to address the asynchronous communication path within application serves has begun, and will ultimately be standardized under JSR 315. To date we have seen independent solutions emerge for Tomcat 6, Jetty 6, and most recently Glassfish/Grizzly.

 App Servers

All of these application servers support scalable asynchronous communication, and ICEfaces is integrated to work will all of them. Additionally, ICEfaces includes the Asynchronous Http Server, that can be deployed along side any application server and provides scalable handling of the push requests.

Because ICEfaces handles all of the connection related intricacies at the framework level, the developer is free to focus on application development, and to that end, has a straightforward Java API to work with. Without question, ICEfaces is the only solution in the market that provides such a comprehensive feature set and an easy to use programming model. The industry is definitely catching on to the revolutionary value of push, and when enterprises decide they need push, they are flocking to ICEfaces. Ajax Push has definitely come of age in ICEfaces.

Technorati Tags:

Posted by steve.maryka at 9:55 AM in Entries by Steve Maryka

Responses (0)

Monday, 7 April 2008

Ajax Push at fisl9.0


I'll be presenting a comprehensive overview of Ajax Push (aka Comet) at fisl9.0 next week. Asynchronous Ajax for Revolutionary Web Applications will cover a wide spectrum on the complete push stack. Java servers and development will be certainly be emphasized, but Jeanfrancois and I have included information that is of interest to more than just Java developers. The talk allows you to compare the development environments available for applications with Dojo, DWR, and ICEfaces and the server APIs available to frameworks on Tomcat, Jetty, and GlassFish.

I'm not sure it's time to coin Web3.0 yet, but the combination of incremental page update and push is really a fundamental, revolutionary change for the web because it changes the way that communication and collaboration can take place.



Technorati Tags:

Posted by ted.goddard at 3:12 PM in Entries by Ted Goddard

Responses (0)

Tuesday, 1 April 2008

Ajax Calendar component with Spacetime extensions


ICEfaces 1.7 will contain a number of enhancements; in particular, we've greatly improved the Calendar component (or "selectInputDate") to full spacetime support. Currently, ice:selectInputDate allows you to choose a date in your current locale:

This has now been extended to full spacetime selection with ice:selectInputSpacetime (simply a four-dimensional generalization of one-dimensional time selection) with accommodations for special and general relativity (without singularities; support for singularities is considered to be relevant only to large-scale commercial deployments, such as those exceeding 20 solar masses, and requires a support contract ).

Ajax Push works well with this new component, since it has both input and output aspects; for instance, to choose the location of a meeting while it is being scheduled by the other participants. Future enhancements to the component will allow spacetime range selection in the form of arbitrary but convex, bounded regions.

Technorati Tags:

Posted by ted.goddard at 4:21 PM in Entries by Ted Goddard

Responses (0)

Friday, 14 March 2008

Ajax with Seam or Spring Web Flow?


When you're writing an Ajax application in Java (particularly using JavaServer Faces or ICEfaces) you will quickly find that you need more powerful abstractions to deal with scopes and navigation.

Of course, for many Ajax applications, navigation will not be necessary at all because an Ajax interface can often be created as a single page, but if you have any sort of workflow in your application, you will need to look beyond what can be done with JSF navigation rules.

Consider the standard scopes provided in the Java Servlet model (request, session, and application). Which of these scopes is suitable for multiple browser windows or tabs opened in the application? Clearly it's not "application", because that spans activity for all users, and it can't be "session" because that spans all activity for a given user. It also can't be "request", because a request spans only a single user interaction (but it can be the ICEfaces "extended request scope" where request spans a full page refresh). This is where Seam and Spring Web Flow come in. These frameworks do a variety of things that can help improve the architecture of your application, but specifically, they both provide additional scopes that work well with Ajax. With Seam, we get "conversation" and "view" scope, and with Spring Web Flow we get "flash", "flow", and "conversation" scopes. (With JSF 2.0, we're looking at "view" and "component" scopes, so those will be excellent to have in the standard.)

Which framework and which scope should you use? I'll provide the details in a talk at TheServerSide JavaSymposium on March 28th in Las Vegas. By presenting how these two frameworks allow you to work with new scopes and how they are integrated with the ICEfaces Ajax framework, you can then decide which configuration is best for your application.

Technorati Tags:

Posted by ted.goddard at 6:53 PM in Entries by Ted Goddard

Responses (0)

Tuesday, 4 March 2008

JavaWorld ICEfaces PodCast


I had a chance to talk with Andrew Glover in a PodCast on Ajax Development with ICEfaces. We cover a variety of topics, including the development practices with ICEfaces that allow you to focus on your application, not Ajax (and certainly not JavaScript), how Ajax Push is a revolutionary change for the web, and how component templating being considered for JSF 2.0 should make component development significantly easier than it is now .

Technorati Tags:

Posted by ted.goddard at 12:28 PM in Entries by Ted Goddard

Responses (0)

ICEfaces and GlassFish at AjaxWorld


AjaxWorld is rapidly approaching (March 18, 2008 in New York) and there are a number of sessions dealing with Ajax Push, ICEfaces, and GlassFish that you should be sure to attend:


Technorati Tags:

Posted by ted.goddard at 11:59 AM in Entries by Ted Goddard

Responses (0)

Friday, 1 February 2008

Ajax at JBossWorld


JBossWorld is rapidly approaching and there are a number of Ajax and Seam talks at the conference:

  • SEAM, AS, EJB3, Hibernate, AJAX4JSF, RichFaces and Facelets
  • Leveraging AJAX and Metadata for Ad Hoc Reporting
  • Seam & JBoss Developer Studio
  • Case Study: EJB3, Seam, JSF, and RichFaces on JBoss 4.2.0
  • JBoss Seam: Integrallis Software
  • Agile Development with SEAM
  • Introduction to JBoss Seam
  • Introduction to Web Beans
  • Advanced Asynchronous AJAX Applications

    I'll be speaking in the Advanced Asynchronous AJAX Applications. Using seam-gen as the starting point, we've produced a variant of the ICEfaces auction monitor that illustrates how Seam Page and Conversation scopes can be effectively used with Ajax Push. I'll also show how Drag and Drop can easily be used with Seam.

    The JBossWorld talk won't contain anything on Portal integration, but we've been working on a number of Portal-related features. One of the trickiest problems is coordinating the JavaScript as it is loaded from different Portlets. Until the Portlets actually encounter each other on the page, they don't know that they're all trying to use ICEfaces (and trying to use the single allowable Ajax Push connection). You will find this (and more) in the upcoming 1.7 release.

    Technorati Tags:

    • Posted by ted.goddard at 2:41 PM in Entries by Ted Goddard

    Responses (0)

    Thursday, 17 January 2008

    Ajax Mobility Reflections


    Mark has a number of interesting comments on using ICEfaces on mobile devices. One that particularly draws my attention is

    Pretty much every input component could be made to simplify its rendering, visually, while not actively being used to input data. This is something that really would not be possible without Ajax.

    To some extent, Ajax is not necessary for building a dynamically changing user interface. DHTML techniques alone are sufficient to build a page with controls that spring to full functionality when clicked on. However, when the page is complex, and the configuration of the controls is context sensitive (such as, don't show the user an address form when you have their address in the database) you can see that Ajax really is necessary.

    Of course, building a simple user interface isn't only a consideration for mobile devices. We're constantly faced with web sites that prompt for redundant information and are generally difficult to use. Just like the one button mouse forced the MacOS interface to be simplified (remember the three different scrolling behaviors applied by the three mouse buttons in xterm?), we'll see improvements to web pages generally as designers work to accommodate the iPhone.

    Technorati Tags:

    Posted by ted.goddard at 2:15 PM in Entries by Ted Goddard

    Responses (0)

    Tuesday, 11 December 2007

    ICEfaces: Solving the Ajax Matrix of Pain for JavaEE

    ICEfaces and the Matrix of Pain

    ICEfaces: Solving the Ajax the Matrix of Pain for JavaEE

     

    One of the underlying objectives we had when we started the ICEfaces open source project was to create the most interoperable enterprise Ajax solution on the market. The matrix of pain that we are discussing here refers to the many configurations that we endeavor to test ICEfaces against.

    As of our 1.6.2 release, ICEfaces is supported across nine different application servers, five integrated development environments (IDEs), five different browser platforms and five third party Java EE frameworks and portals. As far as we can tell the interoperability of ICEfaces far exceeds that of any other enterprise Ajax offering on the market today. Such interoperability however has come at a cost.

    Supporting all of these platforms results in over 1,100 different permutations and combinations of technologies and tools that ICEfaces must be supported and tested against.  Granted some of these combinations are more or less likely to occur in actual practice, but for all practical purposes, our test matrix is quite substantial and growing with every new release. 

    For every third party technology or tool we integrate with ICEfaces we have to plan on allocating the equivalent of a full or half-time engineer for the life of the integration.  Beyond the up front integration efforts, we need to provision support to the user community and forums with respect to the integration and we need to continue that support through any future releases of both ICEfaces and the third party technology or tool.  Every time a third party tool or technology releases a new version we have to retest and often re-integrate ICEfaces. 

    Every time we undertake a new technology or tool integration, the number of possible configurations we need to test ICEfaces against can expand by 2-300 new configurations. In order to accommodate this level of complexity we invest heavily in our own test infrastructure.  With every release we are adding hundreds of new test cases to our automatic regression test suites, and new dedicated hardware to duplicate the most commonly deployed combinations of tools and technologies.

    A practical consequence of this support cost is that we have to be very prudent and careful whenever we decide to take on the support obligations associated with integrating a new tool or technology.  Inherent with each adoption of a new technology or tool is an obligation to provide the ongoing support for it.  Inconsistent and intermittent support for previously integrated platforms is detrimental to the community and can easily damage company credibility and impact the adoption of the platform.  Users often commit considerable investment in time and energy to learn a particular technology and develop applications around the ecosystem it reportedly supports.  Enterprises looking to make this kind of investment must have confidence that the company behind a particular open source solution has the wherewithal, the intent, and the required infrastructure needed to support third party tools and technologies.  They need to know that the ecosystem they are investing in is going to be around for a while and continue to grow.

    I believe we have achieved our objective of delivering the best and most interoperable enterprise Ajax solution to the market, and remain committed to keeping it that way.  Over the upcoming weeks we will be soliciting input from our community with respect to our future 2.0 release of ICEfaces.  Of particular interest will be feedback with respect to which tools, applications, and technologies we need to consider for future integrations.  I encourage you to let us know your thoughts so that ICEfaces is better positioned to meet the evolving needs of its growing community.

     

    Brian McKinney  

    Technorati Tags:

    Posted by brian.mckinney at 12:13 PM in Entries by Brian McKinney

    Responses (0)

    Monday, 10 December 2007

    Ajax with Spring Web Flow and ICEfaces at TheSpringExperience


    TheSpringExperience is on this week, and we're pleased to say that we will be presenting Transparent Ajax with Spring Web Flow and ICEfaces at the conference. One of the main points of the talk is that obtaining Ajax features in Spring Web Flow 2.0 applications is automatic when you include the ICEfaces libraries, but we will also explain how the new scopes introduced by Spring Web Flow are suitable for Ajax applications, and will give a bit of background on how Spring Web Flow and ICEfaces are integrated together. (Spring Web Flow actually exists outside of JavaServer Faces, so this introduced a few interesting challenges.)

    To try out Spring Web Flow 2.0 with ICEfaces pre-1.7 now, you will need the latest code from the respective subversion repositories:

    • svn checkout http://anonsvn.icefaces.org/repo/icefaces/trunk/icefaces/
    • svn checkout https://springframework.svn.sourceforge.net/svnroot/springframework/spring-webflow/trunk
    Then, in the trunk/spring-webflow-samples directory, add an external link to the pre-configured ICEfaces demo:
    • svn propset svn:externals "icefaces-swf-booking http://anonsvn.icefaces.org/repo/projects/icefaces-swf-booking" .
    • svn update
    Build Spring Web Flow with "ant" in the "build-spring-webflow" directory and build ICEfaces with "ant" in the "icefaces" directory. Then, in the "icefaces-swf-booking" directory, copy the following from "icefaces/lib" into "icefaces-swf-booking/lib/global":
    • icefaces.jar
    • icefaces-comps.jar
    • icefaces-facelets.jar
    • jsf-api-1.2.jar
    • jsf-impl-1.2.jar
    "ant" completes the build and you can copy the new .war file to your servlet container (Tomcat, for these particular instructions; omit the JSF libraries for GlassFish).

    The integration of these two frameworks is preliminary, so there are a few points worth noting. Spring Web Flow resource loading (for CSS and JavaScript files) is not yet integrated with ICEfaces. (The demo makes use of direct URLs into the web application in place of this.) The Spring Web Flow custom components for client-side validation are not yet supported (it seemed best to avoid JavaScript conflicts for the first pass). Also, we didn't have a chance to add any Ajax Push features to the demo; most interesting is whether Ajax Push should be represented as a "flow" within Spring Web Flow.

    Please try it out and let us know what you think; we're very excited to have the powerful application abstractions of Spring Web Flow combined with the transparency of ICEfaces. I'll be available at the conference to answer any questions you might have.

    Technorati Tags:

    Posted by ted.goddard at 5:35 PM in Entries by Ted Goddard

    Responses (0)