jQuery Mobile Alpha Release Impressions

Great discussion!

I think that for jqMobile to be a serious contender for dynamic development, it needs to have a Javascript API for building dynamic content.

Unless I am missing something, the best way I have of building a dynamic list right now is to add complete markup using fully formed and styled HTML. The simplified markup you write is not the markup that appears in the page. It gets 'enriched' by the framework. I do not think this is a bad thing at all, but the missing link for dynamic application developers is an equivalent way to do this via Javascript.

The reason that some developers do not encounter this weakness is that they are generating their content on the server and sending it down to the client. This enables the jQM engine to kick in and 'enrich' the markup.

However, when you consider that many developers will want to package their applications up as 'native' apps using tools like PhoneGap, the application at that point must be resident on the device. (This is a significant factor, for various reasons - not least because the Apple AppStore won't accept an app that opens a WebView and points it to a webserver.)

In this case, we NEED a framework that makes it easy to make event-triggered AJAX calls in the background and dynamically update content using Javascript.

At present the best current solution I have yet to come across in jQM is this:

Markup:

Javascript content injection:

Of course, we should not have to delve into the generated page source to find out what jQM has decorated the markup with and add all that js code to emulate it. (Try adding a button! Ouch!) I have read in this thread that the jQM team is exposing a method so that you can basically just do something like this in the next release (see Todd Parker's responses in that thread):

Note that in the example above, I'm adding to the markup at runtime in exactly the same way as I would if authoring the markup at design time. Much more intuitive.

I'd also like to see an additional approach: implement a javascript API of objects and methods that just allow you to append and manipulate the objects programmatically like this:

1. var listItem = new ListItem('Fred');
2. listItem.icon('images/avatars/avatar_1.png');
3. listitem.iconSize=small; //or iconHeight = 16; - you get the idea
4. $('#memberlistview').append(listItem);

I can understand that this final suggestion is a tall order, and may be a fairly large addition to the library. Having it as an optional extension for 'client-resident' applications however, would be a great addition to the framework as it matures, IMO.

I see great potential for this framework, but it's definitely a little green behind the gills right now. But as an alpha it's already quite capable. Production ready for dynamic client-resident apps that would pass as native? Not sure about that...still a way to go.

I'll be watching JQuery Mobile with great interest...

Going Mobile

After two years of travelling, with Sun going down on me, and Oracle rising on the horizon without me, I came back to the Calgary market.
It has been an interesting time for web development, with a significant ICEFaces project under my belt, I took another look into the available frameworks and found some satisfaction in ZK. One of the factors being that I needed a solution that could scale into mobile browsers.
Even though ZK is great on the desktop, ZK Mobile was not really what we wanted for the small form factor devices. They need to re-think their mobile strategy. I think the industry in general is trying to adjust to the fact that mobile Java (JME) is fast giving way to the mobile web, and many will be having to take Javascript much more seriously than we did in the past as fully capable WebKit browsers become predominant.
In an effort to rationalize mobile development across multiple platforms, without having to write native apps in each one, I've been looking closely at the new wave of mobile web technologies.
My current focus is on building AJAX apps with jQuery and the new jQuery Mobile framework, and wrapping them in PhoneGap for psuedo-native apps which can be submitted to the AppStore, Android market, etc.

Watch this space for technical hints, tips (and vents) as I negotiate this new landscape.

Composite Controls with ICEfaces and Facelets

I've been interested in ICEfaces for a while now, and been pleased to see how the adoption is coming along.
One thing I've noticed is how many AJAX and Rich-client frameworks impress with cool widgets but make things complicated through excessive use of Javascript or poor integration at the back-end. I think there's danger in choosing a framework for it's widgets, and there's a risk that people look at ICEfaces purely as a JSF rich component set, not as a complete framework, which it truly is.
Being built on the JSF framework, ICEfaces is a first-class citizen in the JEE world and integrates well with just about any other Java framework. (It can even play nice with a surprizing amount of other JSF component frameworks, like Apache My Faces.)
On top of this, their IDE integration is top notch, supporting just about anything in common use today. After using Eclipse for a while now, I've recently moved to NetBeans due to my new role. Thank goodness the ICEfaces IDE support module is there!
Recently I have had the pleasure of re-aquainting myself with ICEfaces. I finally got the job I've been hoping for since my first brush with JSF a few years back. I'm now a UI architect and it's fantastic to have the company respecting my opinion that ICEfaces/Facelets/JSF is the way to go for enterprise rich internet application (RIA) development.
I even got the opportunity to take my new team on an ICEsoft training course to get them excited about the possibilities. The people at ICEsoft have a great, open approach. They are interested primarily in productivity, and gave all kinds of ideas in how to best use their framework and how to best utilize other tools to be productive. In two days they were saying things like "that's so cool", "this is how web app development should be" and "I'm never going anywhere near Struts again". In ICEfaces, you hardly ever have to think about the request and what values it's sending. You're thinking in terms of components and objects and services - that's the way OO development should be.
I thought that I knew what there was to know about the whole gamut, but there was even a revelation for me: How to make re-usable AJAX enabled components using Facelet composites. I thought I would have to be making new JSF controls and digging into writing TagLibs, Javascript and writing JSF lifecycle event handlers. But I was completely surprized just how easy it is to make a re-usable components that combines the power of Facelets with the coolness of ICEfaces AJAX components. (Perhaps I'll blog on this some time. I had a cool widget up and running in about half a day, and then spent a little more time to extend it.)

Well that's it for now. Take my advice, the next time you think about doing a Java Web App, evaluate ICEfaces. (And don't just look at the component showcase, evaluate the whole framework.) You may find it very enlightening.

All Faces: Java Server Faces, ICEFaces and Facelets in Weblogic Workshop 10.1

It's been a while since I last looked at JSF seriously. The projects I work on day-to-day for the last little while have been Swing and Struts-based.
However, I recently had good reason to delve back in where I left off quite a while ago, and frankly, not much seems to have changed.
Probably the most significant progress is in visual JSF development and AJAX support. We're seeing more developed components and better integration. However, out of the box support for getting up and running with different JSF configurations is still sparse. I feel that things could be a lot smoother with smarter tools support.
JSF is still struggling for dominance over a legacy created by Struts adoption, and an uphill battle against burnt fingers and mis-information about the framework.
I agree with Rick Hightower, that, once configured, you can be more productive and will find things more intuitive than Struts. However, if the goal is to make things as smooth as, say, ASP.NET 2.0, there is still some way to go.

I'm personally rooting for ICEFaces, who have made a fair bit of progress in the year since they Open-Sourced their JSF AJAX framework. ICEFaces is J2EE AJAX 'done right'. The Javascript is managed by the framework, giving a Java programmer the ability to control the state of the UI eficiently and dynamically from the server, using 'AJAX push'.

Having worked with Weblogic 10 for the last little while, I have been impressed with the complete toolset, including the development environment which allows easy integration with Weblogic server on the desktop. Weblogic Workshop is a custom version of Eclipse which includes advanced support for JSF authoring. BEA now includes ICEFaces support within the IDE. However, I ran across a couple of gotcha's which you may be interested in knowing.

ICE Faces support is available as a facet for a Dynamic Web Application in Weblogic Workshop 10.1
Read BEA Dev2Dev introductory article here.
All really good stuff.

Integrating with Facelets involves jumping a couple more hurdles:

BEA support at present is for ICE Faces 1.5.3. It can be added as a Facet to a Dynamic Web Project.
This is not compatible with later versions, and so when integrating facelets, you will have problems if you use the latest downloads from ICE Soft. Make sure you use the icefaces-facelets.jar from the 1.5.3 release if you are using Weblogic Workshop 10.1
The next logical step for BEA would be to include facelets as a project facet dependent on the ICEFaces facet.

Another thing that wasn't immediately apparent to me, is that icefaces-facelets.jar is a complete implementation of facelets, so you don't need to include jsf-facelets.jar in your project. Use icefaces-facelets.jar instead of the default implementation.

Once you get Facelets and ICE Faces configured correctly, you will probably want the IDE to help you with the TAG syntax. However, you will find that you will have little code-completion context help if you use the XHTML format preferred by Facelets.
Eclipse in general is not much help here. MyEclipse has made an effort to correct this oversight. However, all is not lost if you're using Eclipse WTP or Weblogic Workshop.
The trick is to use JSPX format to declare your namespaces. This will introduce code completion for your ICEFaces components, but Facelets tags will still be ignored. You need to get hold of the TLD taglib file for Facelets and place it into WEB-INF/tld.

You can get the Faclets TLD tag-lib file here:
jsf-ui.tld

And here's the final result:

Hope this helps!

CJUG Presentation about Facebook on October 10th

I guess I've been camping too much this Summer to blog!

I presented at CJUG this month on F8 - The Facebook Developer Platform for Java.
I'm being lazy, and so I'll redirect you to the Facebook Event where I posted links for those of you dying to get your apps developed and registered on Facebook.