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?
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.
> 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?
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.
> 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?
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.
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.
> 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.
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:
> 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.
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
On Jun 17, 4:22 am, Nathalie Roman <liekero...@gmail.com> wrote:
> 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:
> > 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.
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.
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.
Avrom Roy-Faderman wrote:
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
On Jun 17, 4:22 am, Nathalie Roman <liekero...@gmail.com> wrote:
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:
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
--
Avrom’s Java EE and Oracle ADF Bloghttp://www.avromroyfaderman.com
--
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
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.
On Jun 14, 10:58 am, Ajay Koranne <akora...@gmail.com> wrote:
> 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?
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
On Jun 22, 6:44 am, skpillai <acurase...@gmail.com> wrote:
> 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.
> On Jun 14, 10:58 am, Ajay Koranne <akora...@gmail.com> wrote:
> > 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?
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
On Jun 23, 8:00 pm, Nathalie Roman <liekero...@gmail.com> wrote:
> 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
> On Jun 22, 6:44 am, skpillai <acurase...@gmail.com> wrote:
> > 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.
> > On Jun 14, 10:58 am, Ajay Koranne <akora...@gmail.com> wrote:
> > > 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?
[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:
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,
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.
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:
> [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:
> 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,
> 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.
|
