Wow. I’ve had some interesting first days at conferences before, but this was exceptional.
My day started out with a meeting of the ADF Enterprise Methodology Group. This was a group discussion led by a panel, consisting of Chris Muir, Simon Haslam, Andrejus Baranovskis, Steve Muench, and myself. But the great thing about this was that it actually wasn’t mostly us talking–we had truly excellent participation from the audience! I’ve blogged about the ADF EMG before, but I want to reiterate here that it’s a great group. We have pretty much daily discussions about all aspects of ADF application design and planning. If you have any interest in ADF development (and if you don’t, I’m not quite sure why you’re here), you want to join. Seriously.
One of the discussions at the group meeting triggered an issue that’s been rolling around my mind for a while: While as I’ve explained before, ADF BC has some excellent hooks for framework enhancements, it could be better yet. Some methods are far too long (which makes it hard to override just parts of them–I’m looking at you, OracleSQLBuilderImpl.doEntitySelectForAltKey()). Some things that are package scoped really should be protected instead (why can’t I call EntityImpl.setOrigData(), if I really want to?). Sometimes the Javadoc is a little too paternalistic for my taste. (“Internal: Applications should not use this method.” Does this really mean the method is subject to change without notice, or is it just that the dev team has decided that it’s too dangerous to let me play with, in which case I’d like to make that decision for myself thank you?) And so on. I had a good discussion with Steve after the group meeting, and I’m going to try to get together a list of “annoying things about the way ADF BC framework code is factored” together to send him. If you have anything to contribute–specifically things that you wish were different about the API (rather than the way the framework actually works at runtime), let me know.
The only unfortunate thing about the ADF EMG was that by the time I got over to Oracle Develop, the hands-on lab I wanted to attend, Oracle BPM, was almost over. So I got to go through about 30 minutes of the lab, that is to say, almost none of it. But I liked what I saw–I’ve never worked with BPM before, but it made a lot of sense and was pretty intuitive. If, say, you’re trying to integrate your services and UIs into a business flow that can then be edited (with relative ease) by business users and analysts, I’d suggest checking it out.
After that, I went to Steve Muench’s talk about ADF debugging. One of the things he covered was a new feature coming down the pipe: Configuing the integrated WebLogic Logger properties directly from within JDeveloper, and converting logging output to an analyzable, searchable form. Another thing I hadn’t known about debugging: The Stack window (that is, exactly what’s displayed in it) is pretty customizable, from the right-click menu. Another thing he mentioned, which is something I did know about but is worth reiterating, is this: You should get the ADF source code; it will massively improve your debugging capabilities if you can debug straight into the framework. You need to get the source code through your support contract (so students, I’m afraid you’re out in the cold on this one), but it makes debugging much easier. Even more important, IMO, being able to step through parts of the source code will make you a much better ADF developer: Documentation is very well and good, but there’s really no better documentation than self-documentation.
By the way, I want to take the opportunity to say congratulations to Frank and Lynn Munsinger, whose book is just about to enter page proofs! I won’t lie, proofs are nasty, but the upside is that they mean the process is almost over! In case you don’t know, Frank and Lynn have been writing Oracle Fusion Developer Guide: Building Rich Internet Applications with Oracle ADF Business Components and ADF Faces, a book that’s due out in January. It’s targeted at a somewhat higher level than the Handbook, and I think the books should make good companions.
One of the things that I liked about today–and it’s supported by Frank and Lynn’s book–is that Oracle is beginning to recognize a group of ADF developers that, I think, it didn’t always recognize in the past (of course, the group was smaller in the past)–people who aren’t brand new to the framework, who might even have been developing with it for a few years, and who want to take things to the next level. I think that’s a pretty substantial portion of my audience with this blog, so I’m especially devoted to it. I also think it shows that ADF is really entering a new phase of maturity in its lifecycle; it’s got a stable and committed developer community (outside the Oracle Applications team, which was always stable and committed). It’s also a broader community. At the ADF EMG meeting this morning, Chris noted that less than half the ADF EMG members have prior experience with Oracle Forms. What was once intended just as a framework to help traditional Oracle developers into the Java world is now being used by people–lots of people–who were never traditional Oracle developers in the first place. Giant days.