J2EE for Forms Developers: A Year in Review. An Oracle White Paper December 2005

Transcription

1 J2EE for Forms Developers: A Year in Review An Oracle White Paper December 2005

2 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

3 J2EE For Forms Developers: A Year in Review LOOKING BACK TO LOOK FORWARD (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 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? LOOKING AT THE VIEW 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

4 a number of properties that influence that item; likewise, a checkbox has a whencheckbox-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

5 define, declaratively, how rows and columns are displayed. In this example, the 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 buttonpressed code should be written. Exactly as you can do with Forms. J2EE for Forms Developers: A Year in Review 5

6 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 users. 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

7 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! Rendering 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

8 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 FACE TO FACE WITH THE COMMUNITY 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

9 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

10 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 U.S.A. Worldwide Inquiries: Phone: Fax: 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.