J2EE for Forms Developers

Document Sample
J2EE for Forms Developers Powered By Docstoc
					J2EE for Forms Developers: A
Year in Review
An Oracle White Paper
December 2005
                 J2EE for Forms Developers: A Year in Review

Looking Back to Look Forward...................................................................... 3
Looking at the View.......................................................................................... 3
  Component Based Functionality ................................................................ 4
  The Design-time Experience ...................................................................... 5
  Componentized Actions.............................................................................. 5
  JSF Page Flow ............................................................................................... 6
  Rendering ....................................................................................................... 7
Face to Face with the Community.................................................................. 8

                                                                J2EE for Forms Developers: A Year in Review 2
              J2EE For Forms Developers: A Year in Review


(A shorter version of this article first appeared in the ODTUG Technical Journal, February 2006.)

As I sit writing this article, 2005 is drawing to a close and our development teams
are working hard on the final builds for the 10.1.3 production release of
JDeveloper. And it got me thinking of how far we have come in a year. Back in
February 2005 I wrote and article for the ODTUG (Oracle Development Tools
User Group) magazine, I introduced the idea that many of the concepts you are
already using to build your business applications can be mapped to the Java world
through the whole raft of features in JDeveloper and the Oracle Application
Development Framework (Oracle ADF).
The main thrust of that article was to show that there are many parallels in the Java
and Forms worlds. In your current environment you rely on the Forms runtime
and record manager to cache data, lock records, manage transactions, and maintain
data integrity. In essence the concept of a framework is something you are already
using in the Forms world -- without actually calling it a framework. And when it
comes to building your Forms application, you use declarative features to set
format masks, trigger points to add your code, and a WYSIWIG editor to develop
your screens. The article set out to show that much of the “day to day” J2EE
development could be done in a similar productive and declarative manner using
familiar concepts, albeit sometimes with different names.
But concerns have been raised. Many of you reading this article will have
questioned whether Oracle can make you successful in the J2EE world. So, a year
down the line what has been happening with JDeveloper and Oracle ADF to bring
it closer to the holy grail of “why can’t it be just like Forms”?

Probably the most significant change over the past year has been the adoption and
inclusion in JDeveloper and Oracle ADF of Java Server Faces (JSF). As a Forms
developer you are used to your user interface being “component” based, meaning
that you build your screen using UI components such as text fields and
checkboxes. More than that, each of these UI items “componentizes” the
functionality of the item. For example, a button has a when-button-pressed trigger and

                                                         J2EE for Forms Developers: A Year in Review 3
a number of properties that influence that item; likewise, a checkbox has a when-
checkbox-changed trigger and a similar set of properties.

Component Based Functionality
With Forms development often driven through the UI design of the screens, JSF
has been a great boon for those of you with a background in Forms. But it’s more
than simply having a pre-defined set of UI components. There are two facets to
JSF development: those who use JSF components, and those who develop JSF
components. Because these components are based on a standard set of APIs,
anyone can develop their own standards-based JSF UI components that can, in
turn, be used by application developers. Two examples of such component sets
are the MyFaces open source project from Apache, and ADF Faces, which comes
with JDeveloper and Oracle ADF.
So what is the benefit to you as an application developer? Well, some really smart
Java people write these components, with loads of really neat features and
advanced functionality, but in essence you don’t need to know how it is
implemented. You just use the exposed functionally and services provided by the
components. Which is exactly what you do with Forms. How many of you know
how Oracle’s development team implements a button in the Forms runtime?
Figure 1 shows an example of the ADF Faces Read-Only Table.

                       Figure 1 – ADF Faces Read Only Table

The table is not dissimilar to a Forms multirow block, but look closely and you will
see that this ADF Faces component provides functionality you might not have
expected, and functionality you don’t have to code yourself. Notice that the
Surname column is sorted and that the header has a small arrow icon to the right
of the label indicating the sort direction. Column sorting comes for free on this
component. Notice also that the table includes several quick navigation features:
“Previous 10” and “Next 10” links, as well as a drop-down list. Again, all for free.
And look at the data in the table itself. This ADF Faces component lets you

                                              J2EE for Forms Developers: A Year in Review 4
define, declaratively, how rows and columns are displayed. In this example, the
email address field is displayed as a hyperlink and every second pair of rows is a
different color. All this functionality is “componentized” within the table and
exposed to the application developer through simple properties.

The Design-time Experience
Which brings us on nicely to the design-time experience. Much of the concern
expressed by the Forms audience has to do with how the design-time experience
will measure up to that of Forms. And again, in the last year we have seen
improvements in this area. JDeveloper and Oracle ADF provide a feature called
the Data Control Palette that gives a tree view of your data model. Now integrated
with ADF Faces, the Data Control Palette allows you to drag the data you want to
display onto the page as JSF components.
But more than just a model for your data, the Data Control Palette provides a
number of operations for that data. Take one example: a database table. There are a
number of standard operations you would want to be able to perform on such a
table: delete, commit, go to next record, go to previous record, and so on. Oracle
ADF and the JDeveloper design time recognize this and make these operations
automatically available as part of the data model. Figure 2 shows how a Delete
operator for the Customers data entity can be dragged onto the page and how
JDeveloper consequently recognizes that this operator can be displayed as a button
or a hyperlink – which means your Delete operation is automatically hooked up to
a UI component, without your needing to write a single line of code.

                       Figure 2 – Operators dragged onto the page

Componentized Actions
Continuing this focus on the componentized view of building the UI, the actions
associated with a UI item (like a button) are easily associated with that item.
Figure 3 shows that double-clicking on the AccountLookup button brings up the
source editor and places the focus in the exact position in which your button-
pressed code should be written. Exactly as you can do with Forms.

                                                J2EE for Forms Developers: A Year in Review 5
                     Figure 3 – Associating code with a button press

JSF Page Flow
And it doesn’t stop there. JSF defines its own controller technology, that is, the
flow of application pages is defined in a configuration file read by the JSF
framework. JDeveloper provides a navigation diagram to define your application
flow, thus allowing you to design the complete flow of your application -- the
Forms equivalent of all those whiteboard sessions with your design team and end
Figure 4 shows a simple example of the JSF navigation diagram (in the top panel)
and the browseCustomers page (in the lower panel). You can see from the
diagram that the page flow from browseCustomers to editCustomers follows from
an action called edit. And the flow from editCustomers to browseCustomers
follows from an action called commit.

                                                 J2EE for Forms Developers: A Year in Review 6
                           Figure 4 – Page Flow Diagrammer

Not only that, but hooking those named actions on the navigation diagram to the
actual user actions is simple as well. In Figure 4, a “Display Orders” button has
been added to the page and the Property Inspector for that button is visible.
When you select the Action property, JDeveloper displays a list of named actions
(which appear as flows on the diagram), so that you can quickly link a particular
button to a particular action, the page flow for which has already been defined.
You might, for instance, define the Display Orders button to call the action
showOrder, which determines that the page flows from browseCustomers to
customerOrders. So, no more having to code Call_Form and Open_Form!

And this is where the technology really starts to sing. The technologies themselves
are advancing at a great pace and introducing a whole range of new features and
benefits such as partial page rendering, in which only the changed portions of a screen
are redrawn, and skinning, which provides the end user with a number of individual
look and feel “skins.” And when it comes to displaying the UI on an actual
physical device, different render kits can be employed with the result that the same

                                               J2EE for Forms Developers: A Year in Review 7
UI can be display differently depending on the physical attributes and limitations
of the end users device -- whether it be a PDA, a phone, a web page or even a

telnet client. Figure 5 shows some examples.

                Figure 5 – The same UI displayed via different render kits

So, the technologies are improving and Oracle is making great strides with the
development and the runtime environment. But, contrary to what some might
believe, this view of “Forms developers can be productive in the J2EE world” is
not a view expounded only from upon high in the Oracle towers. It is something
that is coming from the developers using the tool. Over the past six months, we
have taken the product around the globe to give you, the Forms developers,
hands-on experience with JDeveloper and Oracle ADF. Just as important to us is
the feedback you have given us on using this technology.
We delivered four events in the US including Oracle World, three in Canada, four
in Australia, two in India and seven around Europe; many of the workshops with
100+ developers. We spent time discussing the developers’ experiences, and the
general consensus coming back from these developers: yes, this is something we
can use; yes, we see the parallels with how we are developing now; yes, we think

                                                 J2EE for Forms Developers: A Year in Review 8
that JDeveloper and Oracle ADF is a natural choice for J2EE development for the
Forms audience.
Are there those who don’t think they cannot use this technology? Of course there
are. Some think that the technology is too difficult and concluded that their current
skills will no longer be relevant. But the overriding impression from the
workshops is that most who have come along and taken the opportunity to try this
technology have been, though in some cases surprised, impressed by the
development experience. Those who had experienced earlier releases are seeing
the improvements and the inroads being made in bringing a more productive
environment to the developers. And most of all, they see the opportunities the
technologies can bring to their business.
Benjamin Franklin was once quoted as saying, “To succeed, jump as quickly at
opportunities as you do at conclusions”.
Perhaps the technology is not so difficult after all? Perhaps your skills are still
relevant? With every release, JDeveloper and Oracle ADF improves the
development experience for all developers regardless of their background. And
with every release more and more runtime features aid you, and Oracle’s own
application developers, in building enterprise business applications. So, a year
further on, do you see any opportunities?

                                               J2EE for Forms Developers: A Year in Review 9
J2EE For Forms Developers: A Year in Review
December 2005
Author: Grant Ronald
Contributing Authors:

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200

Copyright © 2003, Oracle. All rights reserved.
This document is provided for information purposes only
and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally
or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically
disclaim any liability with respect to this document and no
contractual obligations are formed either directly or indirectly
by this document. This document may not be reproduced or
transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

Shared By: