Is Oracle selling ADF has some "point and drop and the page is built" app?

[Ajay Koranne]

Hi,

I am on my 3rd ADF 11g project. One thing I learned in my 2 years with
ADF, is the demo and basic tutorials provided by Oracle don't do
justice to the potential of ADF.

When I started ADF, I felt like a complete idiot. Add to that lack of
proper documentation and samples and I was pulling my hair. Anyways,
after getting over that mountain of hurdle I became a convert to ADF.
I realize the potential of it. And I was ecstatic, when I heard Oracle
bought Weblogic. I could see endless potential then, especially now
that Oracle owns Java know! Throw in Webcenter and the various
integration capabilities (OBIEE, ODI, BAM, BPEL, PeopleSoft,
JDEdwards, SAP, Portal & SOA) and I am really excited for the future.

In my view ADF 11g is a complete paradigm shift. Its is very close to
the shift, going from C to Java.

I was one of the few lucky ones! The first project on ADF, the CTO
made it a point that all got the training. Also we followed proper
SDLC and CMM steps. And the project was a huge success.

But, I see the sales division do a dis-service to ADF. Is Oracle
selling ADF has a some "point and drop and the page is ready"? In rush
for sales, is it sold without telling customers what would be needed
for ADF?

I am noticing that the clients, some how seem to think, that you can
just drag a component on to the page and the page is ready to go. Some
how its okay to bring a newbie and he/she should be able to produce
good ADF application in no time. They never realize that to be a good
ADF developer that you first need to be a good Java developer and a
good web developer.

I see developers struggling mightly. And the clients refuse to give
them training and add crazy time lines and you have a classic case of
failed project. Throw in incompetent managers (.Net background,
thinking Java should work just like .Net) and I see a classic recipe
for disaster.

What is the right way to start an ADF project? What should the
recommended qualifications for an ADF resource be? Can anyone comment?
Can we have a discussion? Can others chime in with there hardships?

Thanks,
--ajay

[Avrom Roy-Faderman]

I have to admit, I'm inclined to agree with this. But a couple of
mitigating points:

1) With each subsequent release of JDeveloper, the amount of coding you
have to do goes down. This is *not* to say you can develop any sort of
serious enterprise application 100% declaratively, but things that used to
require a lot of coding (e.g., the vast majority of validation) no longer
do. (When I was working with 9i, I generally told people that the built-in
declarative validation rules were primarily there as *examples*, because
so much validation was too complex for them. I certainly wouldn't say that
about the validation rules provided with 11g.)

2) I'm of the opinion that, with a little work, you can isolate Java
coding to a small part of the team. You can have 80% of your team doing
drag-and-drop development, with the last 20% providing almost all the
coding work necessary. This doesn't mean you need no Java expertise on
your team, but for a lot of teams it means you just need one or two good
Java programmers, and everyone else can do the bulk of the work
declaratively.

That said, I think the idea that using ADF as the Java architecture for
your enterprise is *nothing but* dragging, dropping, and a little bit done
in property inspectors is more or less bunk. You're not going to come out
with a good app that is tailored to the needs of your specific usecase if
nobody on your team knows the difference between a class and an object.

Best,
Avrom

--
Avrom’s Java EE and Oracle ADF Blog
http://www.avromroyfaderman.com

[Grant Ronald]

Interesting comments. I suppose we have a balancing act in terms of how
we "sell" ADF.

One one side there are alot of people saying e.g. "Apex is easy" ", "Why
can't it be like Forms" "Java is complicated" and for these people an in
depth explanation of the full power of ADF is not going to cut it.
Hence we have have presentations/collateral/training for the "ADF for
Forms Developers" and "Fusion Developer with no Java". And if you look
at the up and coming ODTUG agenda you will see a couple of these
sessions as well as hands-on tutorials.

Equally, we have sessions like Binding Internals, ADF Faces deep dive
sessions and I've always loved Steven Davelaar's ADF Faces lifecycle
presentation. So we are certainly not hiding how deep you can sometimes
get with the technology.

Furthermore, we've also try to show the full power of ADF through some
of the "Fusion" presentations where we cover the whole Fusion
development platform (SOA, Java, ADF, Web Center etc) and how the
technology fits into the "big picture".

Personally alot of my effort is trying to show the ease of how you
develop, but I'd never expect an application to be developed without
knowledge of the platform, the language and the technology. However,
what we do try to show is that not everyone in your organization has to
know all the details about all of these technologies.

Regards
Grant

[Avrom Roy-Faderman]

Hi Grant,

I was just emailing back and forth with Duncan about this issue. I'll
repeat here what I said there.

> However,
> what we do try to show is that not everyone in your organization has to
> know all the details about all of these technologies.

I agree wholeheartedly with *this*. But I don't think it always gets made
clear. Duncan was telling me about the Fusion Apps model: The vast
majority of Oracle Apps developers know very little Java. Instead, the a
cadre of fairly elite Java coders forms the OA Framework team, which does
almost everything that requires Java coding, in a sufficiently general way
that it can be declaratively adapted to specific instances. I think that's
a *great* way to proceed--in fact, it's the primary core of my "Extreme
Reusability" methodology--but it's *not* the way that I think most
customers would go after skimming the JDeveloper doc and collateral.

Take a look, for example, at the help topic "working productively in
teams." If this principle should be articulated anywhere, it should be
articulated there. But there's no mention of it--it's all about who
designs the EOs, who designs the VOs, and who designs the pages. (Not that
I don't think that's a useful division. But if you're not going to train
your whole team in Java, it's *certainly* not the most important
division.) Instead, I think a lot of teams have the following experience:

1) They go for ADF without having real Java knowledge *anywhere* on their
team, because they have the impression it's a 100%-declarative framework
(except maybe for a bit of scripting-style Java, which is trivial to learn
if you're familiar with *any* procedural language).
2) They try to build a real enterprise application.
3) They freak out.

Now, as a consultant, that process isn't all that bad for me, because Step
4 is usually, "They hire a consultant to pull them out of the fire." But
for the community generally, I think it would be better if people went
*in* to ADF knowing what they do and don't need. They don't need a team
full of Java experts, or even of solid Java programmers. But they are
going to need someone (or, if they're a big team producing a lot of big
apps, several someones--probably even more than that if they're a *huge*
team like Oracle Apps) to solve their Java problems for them. And if they
don't want to hire or train someone like this, they can at least move Step
4 earlier in the process.

Best,
Avrom

[Grant Ronald]

We are in 100% agreement...I think thats why this group is so
important. Whether it is white papers or presentations at user
groups, this group has the opportunity to use their experiences to shape
the future of ADF projects. I know some have done so already, and I've
been working with some of you on some paper ideas but if anyone wants to
write a community paper on their experience of best practices, we'd be
happy to support that initiative.

Grant

[Nathalie Roman]

Hi Avrom,

I fully agree as well, but the question who needs to be present within
the organisation and the team to streamline usage of best practices
and guidelines.
Which skill-sets does a company need to look for when adopting ADF and
especially someone needs to know the approach for this kinds of
projects so people know it's not 'simply drag and drop'.

It would be great that people would share these experiences with us,
so we can close the gap within documentation, functional and technical
design considerations,etc. something like the GLP-path provided within
the competence center. Depending on your background and skills a
different learning path is required and a different mind-set is
required within the team, at the customer site as well.

Kind regards,
Nathalie

On Jun 15, 7:38 pm, "Avrom Roy-Faderman" <av...@avromroyfaderman.com>
wrote:

[Avrom Roy-Faderman]

Hi Nathalie,

A good point. So, getting more specific, here's what I propose as a
skillset for members of an ADF team. This is a bit tied to my pet
methodology, of course, but I think with a bit of modification it
could work in a reasonably wide range of cases.

20% of team:
-Very good to excellent Java programming skills
-Solid to very good understanding of Java EE
-Solid Java architecture skills
-Excellent knowledge (or ability to acquire it) of the ADF API

60% of team:
-Very basic Java programming skills (ability to write "script-like"
code, understand doc of simple APIs)
-Basic understanding of Java EE
-Understanding of sound principles of UI design
-Strong familiarity (or ability to acquire it) with declarative
aspects of ADF BC, ADFm, ADF task flows, ADF Faces RC

20% of team:
-Basic understanding of Java EE
-Strong familiarity(or ability to acquire it) with declarative
aspects of ADF task flows, ADF Faces RC layouts, regions, command
components
-Basic familiarity (or ability to acquire it) with other components
of ADF
-Basic understanding of deploying applications and troubleshooting
simple deployment problems (plus willingness to ask admin about
complex deployment problems)

Thoughts?

Avrom

[Simon Haslam]

I agree with most of Avrom's suggestions, but think for many custom
apps it will need emphasis on the UI skills too, in particular - that
final 20% need to really need to understand the ADF Faces components
(in particular layout, stretching etc) really well, as well as the JSF
lifecycle, so that the team can deliver apps that look good too.

-Simon

[Steven Davelaar]

Avrom,

In my experience, many of the problems customers face with ADF UI development is related to a lack of understanding how JSF actually works.
Having a good understanding of the declarative aspects is not enough, understanding the JSF page lifecycle and how ADF plugs in, what happens in which phase in which situation, is indispensable to build more sophisticated UI's, and to solve problems.
Imho, core JSF skills are much more imporant for the average UI developer than good Java skills.
And it's not that hard too learn, it's just that most people seem to forget this part.

Steven.

--

Steven Davelaar| Technology Director | Oracle Consulting Tel +31 30 669 8113 | Fax +31 30 669 9966 Oracle Nederland BV | Rijnzathe 6, 3454 PV De Meern, The Netherlands PO Box 147, 3454 ZJ De Meern,The Netherlands | KvK nr. 30096087

Oracle Expert Services | JHeadstart

Klik hier, dan solliciteert Oracle bij jou!

[skpillai]

I agree. We have done a forms conversion project and we tried to put
forms developers and it didn't work out successfully. I have attended
a tech. day event in Oracle office (Dallas, Texas) recently. Many of
'em wanted to know whether forms developers can develop ADF project. I
told that if you solely depend of them, it's not going to work and you
need to have some good java developers. Forms developers need to
undergo Java and ADF/JDev training.

--Sekar.

[Nathalie Roman]

Hi Sekar,

If your talking about a forms conversion project, I understand you
went from a Forms Environment to a ADF environment.
If i'm correct with this assumption, you should have members in your
team that are comfortable with using ADF and especially know how the
framework operates.
They should be familiar with the model, control and view-layer so they
know how everything binds together and how the application lifecycle
process works.
They have the ability to work in a declarative environment, which is
what they've used to do in the Forms Environment, but the application
lifecycle and transaction management will work differently. For
example the Faces Lifecycle, validation- and event-handling is a whole
new area to get to know, so you will indeed need to have some ADF-
members within the team that can tackle these technicalities.

If you have a look at the different wiki-pages and blog-posts that
were defined within this group, you will already have a jump-start on
how to be able to re-use existing pl/sql functionality (ref. avrom's
extreme reusability topics) to give you an idea how you can extend the
framework to be able to reuse the pl/sql investments.

Not all forms developers need to undergo Java/ADF training, you could
divide the team up depending on the skills and experience they have.

Duncan Mills has talked about this during ODTUG and Avrom as well, so
you can partition the skills amongst UI specialists, Service
Specialists, DB specialists, ... In this way you can have more
separation within the framework, so developers can be more specialized
and don't need to know the details of the entire framework to get
started. By starting of with a prototype of the ADF-application, which
will be a specific module or portion of the existing Forms
Application. The team can already build up the knowledge and get
acquanted with the framework so you can approach the new methodology
with an open mind.

And of course another question that comes up, what where the business
drivers to migrate to a JEE Application? In Forms 11g you have a lot
of new functionality and features to modernize the UI, handle
synchronous and asynchronous events to hook into existing or new
business services to extend and modernize the Forms Applications. The
11g release will be an eye-opener for as well classic environments,
such as Forms/Reports, ... and web 2.0 environments where you will see
that both worlds are closing in on eachother which will give the
community and collaboration between teams and skills a boost.

Kind regards,
Nathalie

> > --ajay- Hide quoted text -
>
> - Show quoted text -

[Husain]

I would fully agree. I am also designing a project that converts Forms
to ADF. And its a complete change in the outlook.
The way systems, pages and even business logic are designed in ADF are
different from Forms. (And thats why I was hired to consult them)
The best thing about ADF is that the team was able to develop pages in
no time. Unlike OAF the amount of coding is reduced drastically and is
more flexible for complex applications.
A couple of observations for people converting from Forms:
1. Understand MVC and never ever call Application Module or Queries
from Managed Beans even when its possible to do so.
2. The way UI is developed in Web applications is very different from
Forms. Example Context menus should be never be used in web pages
unless its an internal application where users will receive training.
3. The event handling is mechanism is very different from Forms. Say
in Forms if component A affects component B then you would write code
in a trigger of A. While in case of ADF B will listen to A and act
accordingly. So in ADF we write the actual logic in one of the
listeners of B.

Will post more as I come across. Please feel free to add to the list.

Thanks,
Husain

> > - Show quoted text -- Hide quoted text -

[Avrom Roy-Faderman]

Hi Husain,

[I'm a little worried that I wander off-topic with this, but it's still
related enough that I won't move it yet--Chris, please feel free to move
to a new thread if you prefer.]

I agree with this generally, but I want to make a few amendments/notes.

> A couple of observations for people converting from Forms:
> 1. Understand MVC and never ever call Application Module or Queries
> from Managed Beans even when its possible to do so.

I don't think this is a huge risk for the Forms developers, at least. The
place where I usually see this happening is with *Java* developers who are
new to ADF. A Forms developer is likely to try going declarative first,
and declarative access to the bindings is *much* more accessible than
direct access to the underlying business components, and can't be done at
all by drag-and-drop. By the time a former Forms developer gets
comfortable enough with Java to even think about writing managed bean
classes (which takes a non-negligible amount of time), they're usually
familiar enough with ADF to not make this sort of mistake.

(But this *is* a significant problem for new-to-ADF Java developers. I've
actually seen the following code [*KIDS, DON'T TRY THIS AT HOME--IT'S AN
EXAMPLE OF A BAD PRACTICE*] in a session-scoped managed bean:

ApplicationModule myService =
Configuration.createRootApplicationModule("myorg.myapp.model.MyService",
"MyServiceLocal");

But I can't see a Forms developer doing the above by mistake.

> 2. The way UI is developed in Web applications is very different from
> Forms. Example Context menus should be never be used in web pages
> unless its an internal application where users will receive training.

A little quibble here: Context menus should never be used as the *sole*
way to access a piece of functionality in an extranet web UI. They should
only be used as *shortcuts* for other ways of doing the same thing. But
*duplicating* a function in, say, both a main menu and a context menu
(plus providing an accelerator, which you need anyway for accessibility)
is a great way to cater to *all* levels of users--from new users to power
users. People who don't find the context menu can still do the action, and
people who *do* find it can do it faster. Imagine JDev without the context
menus! Aaaaa!(Even though can't think of any action in JDev that actually
requires that you use one.)

> 3. The event handling is mechanism is very different from Forms. Say
> in Forms if component A affects component B then you would write code
> in a trigger of A. While in case of ADF B will listen to A and act
> accordingly. So in ADF we write the actual logic in one of the
> listeners of B.

I think this is right, although I'd say it a different way--a more MVC-ish
way. I'm assuming (can you clarify) that you mean cases like the
following:

Component A is one of component B's partialTriggers. Instead of writing
logic in component A that changes component B, you write (or, usually, get
for free) logic in component A that changes a value in the model. Then you
write an expression (as one of component B's attribute values) that refers
to the model.

What's missing from your description is that both component A and
component B have logic are really interacting using model layer--either in
the actual Model project or in managed beans that are being used as
non-databound model components. The only logic in *either* of them that
directly refers to the other is the logic in B that says, "recheck model
values when A is used and refresh."

I could see how a (mediocre, non-pattern using) Java developer could have
trouble with this sort of thing--trying to expose A and B as managed
properties and have A change B directly, but I don't really think a Forms
developer could make a mistake with this--what would they be tempted to
do?

It's also worth noting, as a sideline, that there *is* an exception to
this rule. Rarely but occasionally, you need to determine the partial
targets of A's action programmatically (e.g., B is a particular component
in a particular row of a table, and you need to discover the correct row
by skimming through the data being displayed, or B should only be
refreshed if A is used *and* some other condition obtains). In this case,
I don't believe there's any way to write logic on B that will make it
refresh at the appropriate time. Instead, you need to write,

RequestContext.getCurrentInstance.addPartialTarget(B);

in A's firing logic. This, by the way, is also one of the few reasons to
ever expose ADF Faces components in a backing bean.

If you meant in business components too, while the listener system is cool
and often very useful, there are *lots* of use cases (I'd say the
majority, by a significant margin) for letting A change B directly.

[Husain]

Thanks for shedding light on this. Of course I do not have anything
against Forms developers, these comments are based on my personal
observations while developing and mentoring ADF Applications.

I really liked the idea of use of context menus as a convenience to
power users. It is indeed used in most desktop applications and makes
sense while using in Web Applications as well.

What do you think from your experience are the gotchas to avoid? (Can
be transferred to a separate thread)

Thanks,
Husain

On Jun 28, 3:02 pm, "Avrom Roy-Faderman" <av...@avromroyfaderman.com>
wrote: