My developers would like to use Oracle's ADF-Faces rather than generic JSF. The advantages of "drag and drop" programming smells funny to me. Reminds me too much of the 4GL application environments of the early 90's that collapsed when you tried to extend outside of the box that they had drawn around you. Great productivity inside the box, no productivity outside of it.
I have personally used ADF. It gave us so many components that me and my colleagues struggled to make on our own. It is drag and drop to a great extent, but JDeveloper (Oracle's IDE) does not hide the source code from you. It even comes with a Javascript API so you can manipulate the component on the client-side, extending its original functionailty.
Jdeveloper was the only IDE, with great JSF support around year 2005. But, now we have very good JSF plugins for Eclipse, and Netbeans.
Regarding the implementation, you might like to see the difference for yourself. Here is the matrix. However, I prefer ICEFaces, and RichFaces while working with Seam on Eclipse. FYI, I installed Eclipse just to work with Seam. Its easier in Eclipse and well supported by the plugin.
We're using Oracle ADF and JDeveloper (11g) for a fairly ambitious new software project. Here are some random thoughts (I'm sure I could go on all day!):
The Pros:
ADF BC declarative business components when combined with ADF Faces tags on the UI side offer extremely rapid development for a wide range of typical use cases.
The look and feel of the UI you create is incredibly professional. It's well polished and very solid (I've found ICEFaces fairly buggy at times).
Skinning (even ambitious skinning that completely changes the L&F) is a breeze.
Although ADF creates a sandbox (it is marketed as a good tool for those wanting to migrate from 4GLs), it's nowhere near as restrictive a 4GL. You're still in the Java world, and it is still possible (with careful thought) to mix ADF with other tools and technologies.
The Cons:
Despite what the ADF team and the Oracle marketing spiel tells you, it is an immature technology. There are still bugs, there are still strange nuances, and it's still difficult to find answers when things go wrong. This can really slow your team down. The fact that the vast majority of ADF is not open source exacerbates this problem.
Although in theory you can use any IDE (it's all just XML and java, right?), in practice you really will find it almost impossible to use the full ADF 'stack' (ADF BC + ADF Faces) without using JDeveloper to develop your app. There are people that will argue until the cows come that JDeveloper is the best IDE, but it isn't. It's buggy, it's not well polished, it has missing features too numerous to mention, it's a hobby tool compared to Eclipse. It has all the wizards for ADF development though, and these are essential.
If you're a subscriber to the lightweight Spring/Hibernate philosophy (vs heavyweight J2EE/EJB2.0), you may find ADF's prescribed architecture for business layer to be unwieldy. A number of traditional 'J2EE Patterns' have been applied, and the result is the expected extra layers of abstraction (rules on serialization for RMI, etc, etc). I also find the ApplicationModel 'pattern' severly lacking in OO awareness. The wizards auto-generate lots of the code though.
Refactoring can be messy. The idea is that the IDE is smart enough to refactor these objects and change all the relevant XML, but in many cases that's not possible (and manual refactoring is made more difficult by the declarative approach).
its an axiom of 4gl work that the more complex the problem domain then the more effort needed to solve said problem. the benefits are in the miles of code that gets generated for you in the mean time.
development toolset choice must be guided by these axioms. if all you do is window on data then 4gl is the way to go. producing window on data using oracle adf and jdeveloper is fast! and the infrastructure is extendable to just about everything that we've ever been asked of in business applications.
My experience with ADF Faces over generic JSF for in-house applications was extremely positive. Think of ADF Faces as taking JSF and adding those "oh, I wish they had this feature" type things that you're glad are there. For us, the rich UI components were extremely beneficial -- the ADF FAces table component is really nice. Things like "process scope" for dealing with cases where you need data to linger long than a single request but without the problems of backbutton/new windows when storing data in session scope.
I mention "in-house" applications because there's a caveat-- if you want to get up and running quickly and developing in-house apps, ADF Faces is great. However, we ran into significant issues when trying to do things the "non-Oracle way". If we tried to tweak the ADF Faces skin to for example to not show pagination buttons above and below the table component, it was a lot of moving parts (and often required singificant hacks) to get the UI the way we wanted it to look.
There is a lot to be said for having rich, UI components out of the box that just work-- especially when most if not all of them are AJAX-enabled (ADF Faces lets you do partial-page rendering VERY easily).
Obviously the question was not about the whole ADF framework, but only its view layer. Well, ADF-faces are definitely richer than core JSF, no doubt about that. JSF provides you just with very limited core tools. The initial question is equal to asking whether it's better to write plain HTML or use dynamic pages. E.g. these days Ajax is considered an advanced technology, in 5 though years there will be something else: with component-based approach you don't have to rewrite the whole application just to improve user interaction experience. It's not about drag-n-drop as much as about reusability and technology abstraction. The thing is that I think you have to purchase ADF-faces if you are not using some of the Oracle's application servers. The free version of it is MyFaces, which imo still needs a bit work.