Less xml in ADF and move forward to Java EE 6 in 12c

[Edwin Biemond]

Hi,

I am examining the new Java EE 6 possibilities like CDI and Bean
Validation on WebLogic 12c and these frameworks are a great step
forward for java development. One validation framework for the whole
stack.
I know Oracle likes xml above java because then you make new
applications from a web composer and use webcenter. Configure ADF BC
and ADF from a browser. ( great for fusion apps ), but who does this
really ( we already have APEX)

Oracle did a great work in solving things which are not there yet, but
the java community goes forward and like to see that these JSRs are
leading in ADF.

In JSF you have one faces-config.xml and with Oracle you can have many
( ADF Task Flows ), So let's hope in 12c you can use oracle
annotations on managed beans which will be used in one of the ADF Task
Flows.
Also hope to see that all ADF Rich Faces components work on POJO
without the need for ADF BC , With every patch set this goes better.

Integrate Bean Validation support for POJO,JPA and then we don''t need
to add validators in the jspx pages. Maybe even replace ADF BC
entities with JPA. JPA2 and Eclipselink is impressive and is almost
the same now.

I think in the future we will build more on Services ( SOA Suite,
OSB ) and less on Database then it will be great to remove the need
for an ADF DataControl on POJOs ( POJO, WS Proxy , EJB) , who needs
these xml.
Mostly I only define a primary key. ( only great for a Label or
HintText, maybe this can be replaced by ADF annotation. )
Let's make the DataControl window more smart so it can detect CDI or
stateless annotations. So you can drag it to your page and add this
definitions to the pagedef ( adf binding will still use CDI etc.)

Also remove the attributes, action ADF Bindings from the pagedef to
one ADF tree binding definition which is based on a iterator ( use a
tree in single and collection ). the ADF pagedef is becoming so big
and hard to maintain.

Contextual events is nice but to use it in daily life we make new
dummy pojo data controls and add this to pagedef. Too much overhead
and the pagedef is getting bigger and more complex. Would be great to
use CDI or just add an annotation on a method of session bean or a
managed bean. Also for the interception of this event.

I know ADF can be hard too learn when you add all these java features
but it is the future. We don't need ADF become more exotic like Oracle
Forms and come closer to the standard JSF2.0 development. Much easier
to find new developers.

thanks and let me know what you think.

[Amr Gawish]

Put my voice into the queue, I'm really looking forward to it

Best Regards,

Amr Gawish
Senior Oracle Middleware Consultant
     

On Tue, Jan 3, 2012 at 10:09 AM, Anton Gerdessen <a.ger...@gmail.com> wrote:

I could not agree more.
Especially about removing the need for BC and datacontrols.
But I really dont see this happening :(

-Anton

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Rommel Pino]

I was a very proud proponent of ADF Model (JSR 227), but to note the JSR 227 status as WITHDRAWN last year is a nightmare.

Please count me in to magnify Edwin Beimond's voice.

Regards

[G Balaji]

+1

[John Flack]

If what you propose would make ADF less declarative and more coding, I firmly oppose it.  I can code - I can even code Java.  But I don't want to write any more code than I have to - in particular, I don't want to debug my code.  I'd rather use someone else's code that has already been through the ringer of thousands of users.  Still, if you really want to discard the ADF BC Model layer and ADF bindings and write it in Eclipselink and managed beans - you can now.  JDeveloper supports it, or you can use Eclipse with OEPE - which now comes with the ADF View layer.

[Jean-Marc Desvaux]

+1 on John's side.

[Simon Lessard]

Hi all,

I'd like to note that XML is also code, just generated, not compiled and impossible to debug using a debugger since you can hardly put break points in it (although you can place them in the ADF lifecycle as of 11g).

That being said, I wouldn't discard the BC4J, it's a different alternative to other technologies and is not yet obsolete imho. However, it would be nice to have a move lightweight version and support for some annotations, although I don't see how it would be possible for the ADFc layer. As for the ADF Faces component don't relying on the BC, it always has been the case for all components but the <af:region/> which depends heavily on the ADFc implementation, you just need to know how to use them.

Regards,

~ Simon

On Tue, Jan 3, 2012 at 3:31 PM, Jean-Marc Desvaux <jm.de...@gcc.mu> wrote:

+1 on John's side.

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--
Simon Lessard, ADF Architect
CMA CGM SYSTeMS
4, quai d’Arenc, 13235 Marseille cedex 02, France

( +33 6 79 37 39 85 (France)

( +1.418.930.0279 (Canada)

[Edwin Biemond]

Hi,

I like the adf bindings, task flows, jdev wizards and adf bc is really
great. Off course there is no need to replace adf bc entities with
eclipse link but adf BC entities does not do much and with Jpa you can
use coherence etc. and Fix the adf BC big sessions problems , we don't
have that with Jpa and if so we make an ejb cluster which performs
( also good for oracle licenses)

But the java or ejb datacontrol is not doing much and can be easily
out of sync. I like the wizards , rich faces, task flows and the adf
pagedef , and don't hope I have to leave this and go managed beans
with Jpa .

And good to see maven is coming and hope they finally kick out
ojdeploy , gives us libraries to generate a proper ear or an adf
library. The ear generation is so complex

But the biggest problem is finding great developers, the boys and
girls will learn java on the universities and not adf.

Maybe oracle can go 2 ways , adf BC , dc and the java way with Cdi
etc.

Will we see

On Jan 3, 3:53 pm, Simon Lessard <simon.lessar...@gmail.com> wrote:
> Hi all,
>
> I'd like to note that XML is also code, just generated, not compiled and
> impossible to debug using a debugger since you can hardly put break points
> in it (although you can place them in the ADF lifecycle as of 11g).
>
> That being said, I wouldn't discard the BC4J, it's a different alternative
> to other technologies and is not yet obsolete imho. However, it would be
> nice to have a move lightweight version and support for some annotations,
> although I don't see how it would be possible for the ADFc layer. As for
> the ADF Faces component don't relying on the BC, it always has been the
> case for all components but the <af:region/> which depends heavily on the
> ADFc implementation, you just need to know how to use them.
>
> Regards,
>
> ~ Simon
>

> On Tue, Jan 3, 2012 at 3:31 PM, Jean-Marc Desvaux <jm.desv...@gcc.mu> wrote:
> > +1 on John's side.
>
> > --
> > You received this message because you are subscribed to the ADF Enterprise
> > Methodology Group (http://groups.google.com/group/adf-methodology). To
> > unsubscribe send email to adf-methodolo...@googlegroups.com
>
> > All content to the ADF EMG lies under the Creative Commons Attribution 3.0
> > Unported License (http://creativecommons.org/licenses/by/3.0/).  Any
> > content sourced must be attributed back to the ADF EMG with a link to the
> > Google Group (http://groups.google.com/group/adf-methodology).
>
> --
> Simon Lessard, ADF Architect

> *CMA** **CGM SYSTeMS
> **4, quai d’Arenc, 13235 Marseille cedex 02, France*
> *(+33 6 79 37 39 85(France)*
> *(** **+**1.418.930.0279 (Canada)*

[fnimphiu]

My 2 cents

Edwin: "I am examining the new Java EE 6 possibilities like CDI and

Bean Validation on WebLogic 12c and these frameworks are a great step
forward for java development. One validation framework for the whole
stack."

Oracle Fusion Middleware will adopt the full Java EE stack by 12c and
so will Oracle ADF.

Edwin: "I know Oracle likes xml above java because then you make new

applications from a web composer and use webcenter. Configure ADF BC

and ADF from a browser. (great for fusion apps ), but who does this

really ( we already have APEX)"

Very ignorant statement Edwin. We have Internet Explorer, why do we
need Firefox and Chrome? You cannot compare APEX and ADF. ADF is
designed as a metadata framework and this is what the initial JSR 227
(which is no longer, as someone correctly stated) was about. The are
pros and cons with XML, but this is the same for annotations. Note
that the ability of ADF BC to be configurable from a browser is a
feature you will need when developing solutions to run in a cloud
deployment. So though it is developed because Apps needed this, in the
long term it will provide quite some benefit to other organizations as
well.

Also, please don't make the mistake and marry ADF BC too much with
ADF. ADF BC has features we don't yet provide for other technologies.
But honestly, where is model driven list of values in JPA, or named
criterias? So it seems that ADF is able to provide functionality to
standard Java EE that you would not have without.

ADF Business Components is aiming for a specific type of developer,
one that comes from a relational background. Others, like you, come
from an OO background and are closer to JPA, which also is something
ADF can be used with. The whole idea of ADF is to simpify development
and we need to give it the time it takes to develop into all its
possible directions

Edwin: "Oracle did a great work in solving things which are not there

yet, but the java community goes forward and like to see that these
JSRs are leading in ADF"

Of course, ADF will integrate with new standards in Java EE (and you
can see from our effort in supporting Facelets and JSPX documents in
11.1.2 that we are serious about this). However, we also look at
upgrade paths and seamless upgrades which requires us to move on
carefully and not too eagerly go overboard.

Edwin: "In JSF you have one faces-config.xml and with Oracle you can

have many ( ADF Task Flows ), So let's hope in 12c you can use oracle
annotations on managed beans which will be used in one of the ADF Task
Flows."

Annotations will work with task flows probably in 12c time frame. The
concept of task flows is not known by JSF 2.0 and for this reasons,
the annotations you have don't allow you to tell which flow they
belong to (which when it comes to packaging for reuse is a necessity).
So there is some homework we need to do before having ADFc fully
embracing annotations.

Edwin "Also hope to see that all ADF Rich Faces components work on

POJO without the need for ADF BC , With every patch set this goes
better."

Edwin, ADF Faces RC is based on Trinidad and does not have
dependencies with ADF BC. The article you wrote about CDI in WLS 12c
(you used Trinidad) will work the same with ADF Faces running on Java
EE 6. Its just that WLS in JDeveloper 11.1.2 does not support CDI in
this release.

Edwin: "Integrate Bean Validation support for POJO,JPA and then we

don''t need to add validators in the jspx pages. Maybe even replace
ADF BC entities with JPA. JPA2 and Eclipselink is impressive and is
almost the same now."

Why? My impression is that your arguments so far were that you want to
go with JPA (Eclispselink) anyway. So why using ADF BC if you are
happy with JPA ? The discussion ADF BC with JPA entities is an old one
and we had this with TopLink and EclipseLink entities. If you don't
like ADF BC, don't use it. You can go with JPA abd EJB 3.

Edwin: "I think in the future we will build more on Services ( SOA

Suite, OSB ) and less on Database then it will be great to remove the
need for an ADF DataControl on POJOs ( POJO, WS Proxy , EJB) , who
needs these xml. "

In JDeveloper 11.1.2 we already replaced the data control for POJO
(which also is used by the WS DC), which is the sparse bean data
control. With this data control, no metadata is generated until you
start customizing it (e.g add UI control hints). A data control
translates the technical requirements of a business service to a
unified API that is understood by IDEs for declarative development. So
a data control is like your travel adapter allowing you to hook your
laptop to a power socket e.g. in the US.

Ahh, yes - isn't it that the SOA pieces you mention also use XML
metadata (BPM, ESB) ? Why is XML okay here?

Edwin: "Mostly I only define a primary key. ( only great for a Label

or HintText, maybe this can be replaced by ADF annotation. ) Let's
make the DataControl window more smart so it can detect CDI or
stateless annotations. So you can drag it to your page and add this
definitions to the pagedef ( adf binding will still use CDI etc.)"

Not sure I want to follow. The binding layer accesses a data control
and it needs to to make sure it understands the API it is talking
to(remember my comparison of a data control with a tranvel adapter).

Edwin: "Also remove the attributes, action ADF Bindings from the

pagedef to one ADF tree binding definition which is based on a
iterator ( use a tree in single and collection ). the ADF pagedef is
becoming so big and hard to maintain."

Bindings are component models. You can't just have a tree binding (JSF
components demand different models). Action bindings also unify access
to methods and operations. In your article, you used a collection to
build a Trinidad table. This only worked because the Trinidad table
automatically wraps collections in a simplified table model. The real
model it requires hwoever would support additional functionality,
which you don't get from a plain collection.

Edwin: "Contextual events is nice but to use it in daily life we make

new dummy pojo data controls and add this to pagedef. Too much
overhead and the pagedef is getting bigger and more complex. Would be
great to use CDI or just add an annotation on a method of session bean
or a managed bean. Also for the interception of this event."

With 12c you may want to try CDI for this events. Contextual events
are a publish/subscribe eventing that uses the binding layer as its
communication channel. If you find a POJO pattern that does the same
for you then this is okay to use. Andrejus Baranowskis blogged about
this option last year and it works when the Data Control scope is
shared. So its a valid pattern to use. Personally I think that
contextual events are great. The design time - I agree - is too
difficult and this is what I provided feedback to simplify.

Edwin "I know ADF can be hard too learn when you add all these java

features but it is the future. We don't need ADF become more exotic
like Oracle Forms and come closer to the standard JSF2.0 development.
Much easier to find new developers. "

From the perspective of JSF 2.0. ADF is a component model. If you
don't want to use ADF, you would use managed beans instead. It doesn't
make sense to change ADF to CDI if you could use CDI directly. Maybe I
am not getting your point here.

Anton: "I could not agree more. Especially about removing the need for

BC and datacontrols. But I really dont see this happening :( "

ADF BC is not mandatory for ADF Business Components (FULL STOP). You
can use POJO, EJB, WS if you like. I already mentioned why we need
data controls to adapt to a specific business service.

[MARTIN Olivier]

Edwin "I know ADF can be hard to learn when you add all these java features but it is the future. We don't need ADF become more exotic like Oracle Forms and come closer to the standard JSF2.0 development.

Much easier to find new developers. "

Franck "From the perspective of JSF 2.0. ADF is a component model. If you don't want to use ADF, you would use managed beans instead. It doesn't make sense to change ADF to CDI if you could use CDI directly. Maybe I am not getting your point here."

Franck, the point is : it is very difficult to find developers with JSF skills, it is even more difficult to find developers with ADF 11g skills.
For example in France, we did not find any resources with ADF skills, we should hire people from England or Canada. Why ? because most java developers have spring, struts or hibernate skills and few have ever practice with JSF.
Actually, we think it take 3 months to train a java developer with no JSF skills on ADF and start to be efficient. Don't forget that JDeveloper are not their primary IDE (most of the time it is eclipse or netbeans) and they should lean new habits to be efficient.
If you have long term project it is ok, but there is a real problem with 6 months projects (short term) developed by offshore teams (high turn-over)
This ramp up period can be reduce if ADF become more and more close from Java standard like JSF or bean validation.

Regarding XML files discussion, for me XML are ok if you are able to modify them without the need of some wysiwyg interface. I have no problem with task flow config files but I think there is a problem with ADF BC file. Who is able, except steeve, to modify this file without JDeveloper? When you need to merge two changes in such files, it can become a nightmare.

Olivier MARTIN
JEE Architect
Mail : archi...@cma-cgm.com
 +33 4 88 91 17 63
CMA CGM SYSTeMS
A Joint Venture of IBM and CMA CGM

CMA CGM SYSTEMS
Siege Social : 4, Quai d'Arenc, 13002 Marseille
Forme juridique : S.A
RCS Marseille 493 732 713
Capital Social : €10.000.800
SIREN/SIRET : 493 732 713 00018

[Rommel Pino]

 Frank: "ADF BC has features we don't yet provide for other technologies.

But honestly, where is model driven list of values in JPA, or named
criterias? So it seems that ADF is able to provide functionality to
standard Java EE that you would not have without."

This is exactly the point- Its been a long time now and Oracle do not yet provide the "model driven list of values" functionality with EJB/JPA based services. Aren't we using the same ADF Model? It is apparent that those who use the standard EJB/ JPA were treated as secondary citizens. ADF offers Centralized Validation but only applicable for ADF-BC- Since we are using ADF Model, why this centralized validation can't be applied to other services as well?

My ignorant thought,

Rommel Pino

[fnimphiu]

Pino,

no ignorant thought at all. Apparently, ADF BC has features we don't
have for other Data controls. However, in 12c efforts are taken to
close this gap and model driven LOV - as far as i know - are on that
list. So we are getting there. For all technologies other than ADF BC,
the data control becomes our implementation layer for such
functionality. In 12c, you also will have the option to get commit/
rollback operations in ADF working. (btw.: my comment about Edwin's
ignorance was because of his reference about APEX. So don't get me
wrong, its not because of EJB / JPA, which i think is a valid point).

Martin, "From the perspective of JSF 2.0. ADF is a component model. If

you don't want to use ADF, you would use managed beans instead. It
doesn't make sense to change ADF to CDI if you could use CDI

directly". Thanks for pointing out that this sentence may be
interpreted mistakenly. I wanted to point out that ADF provides the
component binding for JSF, which you also can do without it using a
managed bean that implements the component models. This then could use
CDI in th emanaged beans. However, ADF is there to avoid this work, so
we don't want to continue the discussion in this direction.

Btw, I also need to correct another argument of mine, which is that
annotations don't allow managed beans to be associated to a task flow
for later deployment. On a second thought, this is not true as the
deployment is on the project level. So I'll take this argument back
(some late night nonsense - sorry).

Maybe Edwin et all need to go more into details of how they think CDI
could be used within ADF. Who would set the annotations where. If
Edwin meant that the data control layer should be aware of CDI (e.g.
for bean validation annotations) and pick up and enforce those
validations within the ADF lifecycle, then I agree that this will make
sense. Note however that until recently WLS did not support CDI and
therefore the ADF layer is as it is.

Edwin mentioned that having ADF annotations in JPA entities for
defining labels and other UI control hints is acceptable over using
meta data. Is this the common thinking? Would it be okay for you to
add ADF specific annotations to your JPA entities?

[grant ronald]

"I have no problem with task flow config files but I think there is a
problem with ADF BC file. Who is able, except steeve, to modify this
file without JDeveloper? When you need to merge two changes in such
files, it can become a nightmare."

hi Olivier, I've spent a couple of months recently working on some ADF
projects where we used Subversion and to be honest I never really hit
any merge problems specific to ADF BC. That's not to say I never hit
any merge issues but nothing that pointed the finger specifically at
ADF, and using some best practices we minimised any complications.
Infact, some of the XML aware comparisons made merging simpler than if,
for example, the issue was in code.

As Frank pointed out before during the discussion on performance, we can
all roll our various war stories but that often results in no
discernible action. So if you feel there is a specific issue that should
be fixed we need to capture that via a bug logged through Oracle
Support, or we Oracle PMs tend to be pretty responsive to logging issues
we see reported on the forums. We can all really benefit if these
specific issues are captured.

regards
Grant

[Adam Stortz]

I have struggled with many of the same questions/thoughts as Edwin.
Coming from a JSF 1, EJB 3, and Hibernate background, I have found it
somewhat difficult to switch to using 'straight ADF'... mostly due to my
own assumptions and preferences. I have also found some of gaps in the
support for JPA, most of which have been mentioned by others here. In my
opinion, it would be really helpful for people like me if Oracle were to
write 2 tutorials for basic ADF development. These tutorials would create
applications that are functionally identical. One would be built using
'straight ADF' and the other would use things like JPA, CDI, and JSF
annotations. I understand that this would mean that it would be developed
to a 'least common denominator', but I think that is a valuable exercise.
This would allow us to understand the differences more clearly and make a
more informed decision about which way to go.

Thanks,
Adam Stortz

[John Flack]

Olivier - I know what you mean about finding people with the skill set you need.  It is pretty much the which came first - chicken or egg problem, or the getting a job without experience or experience without a job problem.  If people aren't using ADF, then no-one knows ADF, and if no-one knows ADF, then there is less incentive to use it.  I've concluded that it is better to get people who show the ability to learn, to find out how to do what they didn't know before, willing to read the docs, work through the tutorials, watch the ADF Insider videos, go to ODTUG and OpenWorld.  These people will be successful no matter where the technology leads us (even to -gasp- .Net) .  If they come to us knowing some of the technologies, all the better, but even then they need to be flexible, and not fixed on doing things the same way they've always done it.

[grant ronald]

I agree with John, even if we take ADF out of the equation there is
often a requirement for anyone coming into a project to be flexible and
skill up. Even if you have, for example, JEE5 skills what happens when
your next project is JEE6 or 7 or 8 - or adopting the latest framework
flavour of the day (or home grown version)...you will often skill up
your existing resources.

All that said, I sympathise that ADF is, in the great scheme, a "newer"
technology and resources are less in abundance that other core JEE
skills - but we are on a steep uptake of a technology which is going to
be core to one of the biggest software companies on the plant (love it
or hate it) and so I'd be betting on it rather than against it.

Ok, so that debate to one side, one of the aims I have is trying to help
you become more successful with ADF. As John points out, we have
tutorials, ADF Insider, ADF Insider Essentials, we have 4 ADF books, we
have developer guides,3 or 4 different OU course - and we are working on
more - an on line Advanced ADF course as well as architecture and best
practices training. We're working on content and delivery which we
asked you for feedback about late last year (our ADF questionnaire) - if
there are any other specific requests which you need to get your people
skilled up, then feel free to ping me off this DL and I'm happy to see
how we can help.

regards
Grant

[Lynn Munsinger]

This is a lively discussion and I appreciate all the opinions. Of
course we all understand that these aren't just opinions from the
sidelines, but real issues and concerns based on your real-world
experiences, and that is exactly the kind of thing that this group is
great for. What we can do now, as Grant points out, is to provide
reproducible test cases for current issues with ADFbc. What we can do
for future consideration is take the discussion of annotations vs XML
to our internal development teams, which I will take the lead on. And
we can all work together to spread the understanding of ADF. Good Java
skills are still needed in ADF application development - I think a
recent graduate with core Java skills would be quick to pick up the
parts of ADF that tend to trip up traditional business application
developers - task flow memory scopes, for example. Anyway, if we "bet
the farm" on ADF as Oracle has done, then it's up to all of us who
understand all the skills necessary to help Java or ADF newcomers
alike to succeed. That means doing the (sometimes annoying) work of
filing the aforementioned bugs and continuing to spread knowledge via
all the different channels and aimed at all the different skill sets.
And to Rommel's point regarding the citizenship status of JPA-backed
ADF developers...
there is some hard truth to this and that is ADFbc is the chosen path
for Oracle, meaning that even as we support multiple data controls
(and we have implemented validations on the data control layer), ADFbc
has development priority internally.

Please feel free to contact me if you have concrete suggestions to add
to Edwin's original post. And as always, contact your favorite Product
Manager if you need help filing a particular bug.

Regards,
Lynn

[fnimphiu]

I took the liberty to create a new thread for the JPA / CDI and
tutorial requests

http://groups.google.com/group/adf-methodology/t/4054edbfa069c1ea

This way we can focus on the requirements and improvement you want to
see for ADF in combination with EJB / JPA. I like us to post it in a
constructive manner based on functionality we have available in 11.1.2
(as this is the latest in terms for less XML and closer to 12c). If
possible, if you could provide use cases or steps how developers would
use the suggested feature it is easier for Lynn to discuss this with
our development team. Lynn, I hope you are okay to keep the discussion
on the EMG forum instead of moving it to decoupled private mail
communication which would be difficult to moderate and synchronize.

[Edwin Biemond]

Hi everybody,

Thank you for all your comments, great to see the passion.
The apex comparison was , to make everything more spicy. the apex vs
adf discussion is gone lately. :-)

And many many thanks that adf is moving forward , I feared that this
is it , for the next years (because fusion apps is released. )

I know is hard to find developers, even in NL .
I noticed the trend with new applications , that we only build on
( soa or osb ) services together with some ejbs. This leads to a lot
of ws proxy services where we decouple , make usuable entities of it
and generate an adf data control on it. And because the customer
likes lov , query panels etc ( they saw the demos ) we need to do a
lot , to make it working.
Because of this and hard to find adf developers ( which can do more
then adf BC ) a few companies went to jboss rich faces , Jpa and
managed beans or even moved to .net

thanks Frank for starting a new Jpa discussion.

[Andreas Koop]

Hi,

eb wrote:
> Less xml in ADF and move forward to Java EE 6 in 12c
and

>I know Oracle likes xml above java because then you make new
> applications from a web composer and use webcenter.

XML for the UI Views are quite fine. That should not be changed;)
Additionally, as far as I know there is currently much XML in order
for beeing customizable through MDS. To that fact I think there will
still be much XML in the next ADF releases.

Nevertheless I would like to see more annotations where appropriate,
e.g. Beans in pageflowscope, and generally where CDI fits best. In
case of managed bean declaration it also would reduce code size: 1
Java LOC vs. 3 (readable) XML LOC;)

> ADF Contextual Events
Projects with extensive use of adf contextual events, are not easy to
maintain respectivly introduce a new developer into running adf
project. Additional to Shared DC, a contextual communication through
CDI Events would be great!

eb wrote:
> We don't need ADF become more exotic like Oracle
> Forms and come closer to the standard JSF2.0 development. Much easier
> to find new developers.

+1. Even more: I hope to see the ADF Taskflow concepts standardized in
JSF2.x or JSF3.

Generally speaking: I would like to see ADF beeing so well designed
and implemented that it influences the Java EE 7/8/* Specs (like
Hibernate did for JPA or Spring for CDI and more). But from my
experience I really cannot imagine this could ever happen ;)

But the most important thing for every upcoming ADF releases should
be: Stableness. One less bug rather than one more feature!

AK

[Donovan Sherriffs]

My own secret wish is for the best of both worlds I guess.

I find BC great for forms migration and moving forms developers into
the ADF world. (they become productive much quicker note: we have both
java (migrating from WAS/RAD to Weblogic/ Jdev) and ADF (forms
migration) stuff.
How this would work in practise is that a set of ADF specific
annotations could be developed would have to be and could be managed
via a wizard and nice helpful screens and lessens the need for too
many xml files (really not overly fond of the jazn-data.xml etc).
(your choice to use the ADF annotations or not)

Maybe I am wrong here I was trained to be as vendor neutral as
possible but use the don’t use them sets of helpful annotation that
remove some donkey work would be nice.

Data controls also would need to be expanded to work seamlessly with
ejbs, web services etc . (not that far off really) Making a LOV
framework that will work for JSF (EJB or web service backed) is quite
straight forward and hopefully will be with us soon.

As for people they are not found but created - give me 3 months with
any sharp java dev with web framework experience and I will give you a
productive ADF developer (not expert). It is just a matter of finding
an ADF expert to guide you.

But that goes for any change of technology and most important a good
attitude.

Note: I come from a heavy JEE background building big systems (JSF
(Trinidad, tomahawk, myfaces etc) and EJB3) but have been working with
ADF (and forms migration) for about 2 years.

[soumik]

Hi,

I am just sharing my experience with oracle ADF. I have around 4 years of experience in oracle ADF and  done quite a number of large projects whose backend services are spring/hibernate and not ADF BC.In this scenario i had to use ADF faces and ADF controller(taskflows) with java based backed services with normal JSF binding.Some of the ADF faces cool components like af:listofvalues,af:query,af:calendar etc etc. are really hard to bind with java based model and only source of documentation is adf rich component demo war file.

My point is adf faces,adf controller these two are  also the part of Oracle ADF framework apart from ADF bc. And it is also possible to use the features of ADF faces and Taskflows with java based services directly.Then why there is virtually no documentation/help/examples on that front. In real world ADF BC is not the back end services always.

It would be great for developers like me if oracle people provides some tutorial in this front.

[John Flack]

Moderator hat on:

I allowed this post, because the topic started some good conversations before, and there may be more to say.  However, soumik, I hope you read more of this thread than the message that started it - and I hope you realize that posting on an old thread is considered rude by some people.

 

Moderator hat off.  Developer hat on:

When I started with ADF, I really appreciated that I only had to know a little Java, and that ADF does so much declaratively.  However, it does support EJB (JPA) Models, and I have some developers working for me who have developed two good ADF applications with no ADF BC and no ADF Bindings.  They had no trouble using ADF Faces for their View

[fnimphiu]

Just to bring another aspect in. ADF binding can be used with POJO and EJB models as well. So ADF BC is not the main business service (though admittedly the most documented). I just did a presentation on ADF programming best practices that pointed out that the binding layer, controller and view layer work the same for all the supported business services (including POJO), which means documentation can be easily adapted to the business service in use.

For tutorials and documentation for how to use ADF Faces with managed beans. Here we need to balance our available writing resources. Since the majority of our users work with ADF - and given ADF is there to simplify things (e.g. in opposite to hand-written component models) - we do focus on this part of the technology stack. To be honest, the number of requests we get for tutorials on the ADF Faces component stack alone is not of high volume. With the component demo however we give you both: a runtime sample plus the code to implement the feature. How-to query data from POJO or EJB is what I think is well documented on the Internet and ADF Faces doesn't differ from any other JSF here. All you then do is to read that data in to the component model and this is what the component demo provides you the code for. I agree however, that the component demo doesn't provide the narrative of a tutorial, but as said, we need to balance our writing resources.

Frank

[hxshi]

I agree. Actually, using spring/hibernate  in ADF framework  is simpler than using ADF BC.

--

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.