In reality the code for this framework becomes pretty simple once things are setup. The Servlet needs to be set up within the web.xml and can be invoked like any other Servlet. The web.xml would have something like this...
Initially I setup a simple function that echoed any text that a user typed into an input field. I was able to get some help from a colleague, Varad Ramamoorthy, on a second function, which polls the Servlet every 60 seconds for a time value to display. This to me can add real value to a portal, where users can receive an alert without refreshing the screen. I am thinking more about a call center type of application then an employee workplace in this scenario.
I was accessing the Servlet using the application path, i.e., /wps/PA_0_0_F/MyServlet or something like that. The problem with this is you have to wait until the .war file is installed and then determine the path. Varad was able to show me how I could use the renderRequest.getContextPath() to do it much easier. We also started taking an initial look at performance issues and how these functions may affect in session memory. We are going to dump the full code along with lots of explanations in an article over the next few weeks, which we will publish somewhere soon.
Admittedly we are just scratching the surface, but I always look at these things as an evolution of functionality and the skills required to take advantage of new technologies. And of course, as always, I often proceed with caution, because I often have to advice clients on what is the best approach. I would be curious about where folks are using this in their portal, if at all and any advantages, disadvantages they have found?
Ajax in Portal - Part II