Thursday, November 23, 2006

Lack of ADF Swing documentation

Well, this hasn't been the most active blog around. But that's ok - noone knows about this blog and noone has been to this site yet - but maybe someone will drop by, oneday ;-)

I went to UKOUG 2006 Conference and Exhibition last week. That was very informative and I think a learned a lot and now have a list to dig into when I have time. Not very much about ADF Swing though, but as Grant Ronald says in this post the 2 ADF Swing presenations were quite popular.

Grant seems to have learned that from UKOUG that ADF Swing documentation is lacking, and hopefully he is a position to change that. He asks what information is needed. I commented on his post on what documentation / demos / tutorials I would like to see. Here's my comment for reference:
Hi Grant, I think I attended all your presentations at UKOUG and found them all really good and informative.
I also noticed the interest in ADF Swing which came as a pleasent surprise to me as I thought I was (almost) the only one trying to use ADF Swing.

What I would really want from Oracle is to acknowledge that a large portion of their users/customers do want a rich client interface. Most (at least many) of Forms users are still running Forms 6 in a client/server environment (at least many of UKOUG attendees) so that should tell us that people (not everyone at least) wants or needs a web interface. I think ADF Swing is really a more logical progression from client/server forms for the end user than moving to a web UI (although I look forward to see the next ADF Faces release with (hopefully) AJAX enabled components, that could change my opinion on that).

I have been using ADF Swing (formerly JClient) for quite a few years and have to admit that it keeps getting better by every release, in just a few more years it should really get usable and productive.

A fully operational ADF Swing demo would be nice to have. By fully operational I'm not talking about EMP/DEPT in a single dialog app connected straight to the database (client/server). A MDI (multi document interface) app deployed in 3 tiers using editable tables, client side field formatting and simple validation (eg. only allow numbers entered into number fields, highlighting missing required fields and fields that fail bc4j validation on post/commit). Calculated (transient or not) fields that are updated/recalculated when other fields are changed would also be a nice feature to see in a demo and/or tutorial, and yes these have to work in 3 tier deployments.

A good guide to configuring and tuning ADF Swing applications would be very useful. Most documentation I have seen on tuning application modules, connection pools and application module pools is centered on web (jsp/jsf...) applications and if the mention ADF Swing at all is by saying "this is not recommended for ADF Swing Applications." and that's about it - really useful ;-)

One issue I am facing and would like an answer to is how we should partition applications into application modules in a MDI interface. If we use a root application module and put other application modules inside of that like is recommended by most ADF docs (I tend to have 1 appmod per screen (JInternalFrame)), then I only have 1 connection to the DB and only 1 db transaction. If the user is halfway through entering data in one screen and then goes another, enters data commits or rollbacks it affects the other screen as well. Either commiting incomplete data which can fail validation and is confusing for the user as he is not looking at the screen where the invalid data is or rollbacking the whole lot (both screens), even more frustrating user experience. We do not nest application modules because of this issue but the drawback is that every user then has n-many (n=number of appmods) DB connections. Is there any known better way for this?

Well, this is getting quite long and should keep you busy for some time, just let me know if you get bored and I can tell you about a few more problems/annoyances I've encountered in ADF Swing - which by the way I like very much even though it's not really very productive yet and lacks a lot of documentation.

Friday, September 29, 2006

Purpose of this blog

This is my experiment in contributing to the community of ADF Swing developers. I feel ADF Swing is being "left out in the cold" by Oracle and hopefully the voice of us the developers will be heard.

I have been developing with ADF Swing (formerly JClient) for a few years now (mostly one big project) and have stumbled upon quite a few bugs and annoyances along the way. I'll try to mention some of them here and the solutions I have found.

I will not guarantee regular updates and/or much activity as I will do this in my own spare time, which is not too much these days. But I'm willing to invite others to post entries here if anyone is interested.