pdf. Oracle ADF Enterprise Application Development Made Simple 2nd Edition . eBook versions of every book published, with PDF and ePub files available?. Oracle ADF Enterprise Application Development – Made Simple 2nd Edition – Free Books Download PDF / Free Books Online / Free eBook Download PDF. Oracle ADF 11gR2 Development Beginner's Guide . , McGraw-Hill, and Oracle ADF Enterprise Applicafion Development – Made. Simple .. development life cycle for an enterprise application using ADF. .. For example, PDF files will be preferred .. Creating a simple ADF application in JDeveloper.
|Language:||English, Spanish, Dutch|
|Distribution:||Free* [*Registration Required]|
Oracle ACE Director. • Author of “Oracle ADF Enterprise. A li ti D l t M d Si l ”. Application Development – Made Simple”. • Partner in Scott/Tiger. Sten Vesterli. Application Development. Made Simple. Successfully plan, develop, test, and deploy enterp applications with Oracle ADF. Sten E. Vesterli. [pAfi/Tl enterprise. What better way to learn ADF than by completing an entire enterprise application development project, step by step? This book leads you through the whole.
Testing Your Application Initial tests Working with JUnit Using JUnit to test code Writing good unit tests The unit testing ADF applications Preparing for unit testing Setting up a test project Adding default testing The real unit testing example Adding a test case Implementing logical delete Re-testing Automating unit testing User interface tests What should you test?
Customizing Functionality The reason for customization The technology behind ADF customization Applying customization layers Making an application customizable Developing customization classes Building the classes Implementing the methods Deploying the customization classes Enabling seeded customization Linking the customization class to the application Configuring customization layers Using resource bundles [ ix ] www.
Securing Your ADF Application The security basics Authentication means knowing your user Authorization means deciding on access The Oracle security solution Alternative security Security decisions Performing authentication Performing authorization Where to implement security Implementing ADF Security Selecting a security model Selecting the authentication type Selecting how to grant access Select a common welcome page Application roles Implementing the user interface security Securing task flows Securing pages Using entitlements Implementing data security Defining protected operations Protecting an entity object Protecting an attribute Granting operations to roles Users and groups Mapping the application to the organization Example users and enterprise roles Assigning application roles Running the application Removing inaccessible items Summary [x] www.
Internationalization Automatic internationalization How localizable strings are stored Defining localizable strings Performing the translation [ xi ] www. You know that actual development work is only one part of a successful project and that you also need structure, processes, and tools.
Along the way, you will be building a Proof of Concept application, but you will also be setting up and using all of the professional support tools you need for a real-life project. This book will take you through the entire process of building an enterprise ADF application, from the initial idea through the Proof of Concept, tool choice, preparation, coding the support classes, building the application, testing it, customizing it, securing it, and finally, deploying it.
What is an enterprise application? Enterprise applications are the strategic applications in the enterprise. They will handle critical business functions and tend to be big and complex. In the past, it was acceptable that users had to take training classes before they were able to use the application, but today, enterprise applications are also required to be user friendly and intuitive. As they are deployed throughout the organization, they will need sophisticated security features.
Enterprise applications will remain in use for a long time because of the cost of developing and implementing them. Typically, this means that an enterprise application also has a lot of different screens where the user will interact with the system.
However, it is also possible that the complexity of the enterprise application is hidden from the user; a good enterprise application might seem deceptively simple to the average user.
Development team The complexity of an enterprise application means that it will have to be built by a larger team. It will use several technologies, so you need people skilled in all of the relevant areas. You will need to have people working in parallel on different parts of the application in order to develop it within a useful timeframe because of its sheer size. An enterprise application cannot simply be partitioned out among developers because of the interdependencies among the different parts of the application.
Instead, development work must be carefully planned so that the foundation is laid down before the rest of the house is built while, at the same time, allowing for the inevitable changes as the project progresses.
This book assumes that the entire team will be using Oracle's free JDeveloper tool for all work. The choice of IDE can be the subject of almost religious fervor, and some projects allow each developer to choose his or her favorite IDE. However, in an enterprise project, the benefits of having everyone use the same tool clearly outweighs any minor benefit achieved by using other IDEs with marginally better support for one or the other task.
In addition to the IDE, you will also need source control—a server holding all of the different versions of the development artifacts and a client on each development workstation. This book uses both Subversion and Git as examples of how to use source control in an enterprise project with JDeveloper. Another important tool is an issue-tracking tool. This can be used to track defects in code as well as ideas, development tasks, and many other things. In a small project, it might be sufficient to build applications directly off of the IDE, but in an enterprise application, you need a tool to ensure that you can build your project in a consistent manner.
This book uses Ant as an example of a scripting tool for the ADF projects. Lifetime of an enterprise application Enterprise applications are not casually thrown away and rebuilt because of the effort and cost involved in building them. Indeed, many organizations are still running enterprise applications built more than a decade ago. The longevity of enterprise applications makes it extremely important that they are well built and well documented. Most developers will be familiar with the pain of having to maintain a poorly documented application and understand the need for a good documentation.
However, while documentation is important, it is just as important that the application is built in a recognizable, standard way. That is why this book advocates using the ADF framework in its intended way so that the future generations of developers can look at the code and immediately understand how the application is built. What this book covers Before your organization embarks on building an enterprise application using the Oracle Application Development Framework, you need to prove that ADF will indeed be able to meet the application requirements.
This chapter contains step-by-step instructions and can be used as a hands-on exercise in basic ADF development. Once you have proved that ADF is capable of delivering the necessary functionality, you need to figure out which components will be part of your application and estimate the total effort necessary to build it.
Chapter 2, Estimating the Effort, will provide checklists of tasks that you must remember in your estimate as well as some guidelines and estimation techniques that you can use to calculate how much time it will take to build the application. Chapter 3, Getting Organized, explains the skills you need to build an enterprise application and how to organize your team.
It also explains which tools you need in your enterprise project and how you should structure your code using separate workspaces connected through the powerful ADF Library functionality for maximum efficiency. For the team to work efficiently toward the project goal, each developer needs a development workstation with complete integration of all the necessary tools. Chapter 4, Productive Teamwork, describes how to set up and use the Oracle Team Productivity Center, which serves as an integration hub, connecting your issue tracking system for example, Jira and other tools to JDeveloper.
It also explains how to work effectively with Subversion and JDeveloper together for version control. With your workstation all set up and ready to go, you need one more thing before starting development in earnest: For a small application it might be OK to just start coding and work out the details as you go along. However, in an enterprise application, the rework cost of such an informal approach can be prohibitive. Chapter 5, Preparing to Build, explains the task flow and page templates you need to build a uniform user interface in an efficient way.
It explains why you need your own ADF framework extension classes and how to build them. Now that all of the infrastructure and templates are in place and the development workstation has been configured with all necessary connections, it is time to prove the entire development flow.
The application is built in a module manner in separate subsystems and integrated together in a master application to illustrate how a large enterprise application should be structured. By the end of this chapter, you would have proved that the entire enterprise toolset is functional, and you would have rebuilt the Proof of Concept application using the correct enterprise methodology.
It will not be sufficient to have a collection of test scripts that must be manually executed—these will not be consistently executed and will surely become out of date over the lifetime of the application.
Your tests must, therefore, be automated so that they can be executed as part of the build process. Chapter 7, Testing Your Application, explains how to write code tests in the form of JUnit test cases and how to use Selenium to record and playback user interface tests.
Your organization will, of course, have graphical standards that the application must adhere to. In an ADF application, the look of the application can easily be modified in a process known as skinning.
By developing several skins, you can even deploy the same application multiple times with very different visual identities—an invaluable feature for independent software vendors. Chapter 8, Changing the Appearance, explains how to use the powerful skin editor available in JDeveloper 11g Release 2 and later versions to create Cascading Style Sheets CSS to create a new skin, which corresponds to your enterprise visual identity, for your application.
Looking at the requirements for your application, you might identify a number of pages or screens that are almost, but not quite, identical. In many cases, you don't have to develop each of these individually—you might be able to develop one master page and use functional customization to provide different groups of users with different versions of the page.
The ability to easily customize an application's functionality is one of the truly outstanding features of the Oracle ADF framework. Here, you benefit from the fact that Oracle has developed ADF for real life, large enterprise applications like Oracle Fusion Applications. If you are an independent software vendor, producing software for sale, you can use this feature to easily customize a base application for individual customers. Your enterprise application needs a robust, role-based security model.
Once the individual parts of the application have been built and tested, it is time to build a complete deployment package. Chapter 11, Packaging and Delivery, describes how an enterprise application deployment package is built and how the development team can set up their own standalone WebLogic server to ensure that the deployment package will work when handed over to the operations team.
An enterprise application might have to be made available in several languages. Appendix, Internationalization, explains how internationalization works in ADF and how to produce a localized application. How to read this book This book follows an enterprise application from inception to final delivery, and you can read the chapters in sequence to learn a proven method for successfully building an enterprise application that meets the business requirements on time and on budget. However, many chapters can also be read on their own if you just need information on a specific topic.
For example: Let's get started! The examples in this book use Version The examples will also work in JDeveloper 11g. Additionally, you need the following: This book uses and recommends Apache Ant Who this book is for Whether you are a J2EE developer looking for a more productive way to build a modern web application or you are an experienced Oracle developer who wants to start using Oracle's next-generation tools, this book will guide you to a successful enterprise application.
With basic knowledge of Java, JDeveloper, and databases, you can easily follow this book. Conventions In this book, you will find a number of styles of text that distinguish between different kinds of information.
Here are some examples of these styles, and an explanation of their meaning. Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: Warnings or important notes appear in a box like this.
Tips and tricks appear like this. Reader feedback Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply send an e-mail to feedback packtpub. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.
Customer support Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your download. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us.
By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http: Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title.
Any existing errata can be viewed by selecting your title from http: Piracy Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously.
If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at copyright packtpub.
We appreciate your help in protecting our authors, and our ability to bring you valuable content. Questions You can contact us at questions packtpub. You can compare the situation at the start of a project to standing in front of a mountain with the task to excavate a tunnel.
The mountainsides are almost vertical, and there is no way for you to climb the mountain to figure out how wide it is. You can take either of the two approaches: You don't know how wide the mountain is, so you can't tell how long it will take to build the tunnel.
In addition, you don't know what kind of surprises might lurk in the mountain—porous rocks, aquifers, or any number of other obstacles to your tunnel building. That's why you should build the pilot tunnel first—so you know the size of the task and have an idea of the obstacles you might meet on the way.
The Proof of Concept is that pilot tunnel. Therefore, this section will only give you a very brief overview of ADF—there are many whitepapers, tutorials, and demonstrations available at the Oracle Technology Network OTN website.
Your starting point for ADF information is http: Enterprise architecture A modern enterprise application typically consists of a frontend user-facing part and a backend business service part. The frontend part The frontend part is constructed from several layers. In a web-based application, these are normally arranged in the common model-view-controller MVC pattern, as illustrated in the following figure: The controller layer is in charge of interpreting user actions and deciding which screens are presented to the user in which order.
The model layer is representing the backend business services to the view and controller layers, thus hiding the complexity of storing and retrieving data. The controller doesn't have to worry about how to store data in the data service because that is the task of the model.
Other frontends An enterprise application could also have a mobile application frontend or even use existing desktop applications, such as Microsoft Excel, to interact with data. In the ADF technology stack, all of these alternative frontends interact with the same model, making it easy to develop multiple frontend applications against the same data services. The backend part The backend part consists of a business service layer that implements the business logic and provides some way of accessing the underlying data services.
Under the business services layer, there will be a data service layer actually storing persistent data. Typically, this is based on relational tables, but it could also be XML files in a filesystem or data in other systems accessed through an interface.
Edwards, and many other applications Oracle has acquired over the last couple of years. If it's good enough for Oracle Fusion Applications, arguably the biggest enterprise application development effort ever undertaken by mankind, it's probably good enough for you, too.
This is a very rich set of user interface components implementing advanced functionality in a web application. This implements the features of a normal JSF controller, but is extended with the possibility to define modular, reusable page flows. ADFc also allows you to declare transaction boundaries, so one database transaction can span across many pages.
This implements a common backend model that different user interface layers can communicate with. This is a highly productive, declarative way of defining business services based on relational tables. You can see all of these in the following figure: However, other routes might be appropriate in some situations; in the frontend part, you could use ADF Mobile for smartphones and tablets or ADF Desktop Integration to access your data directly from within Microsoft Excel, and in the backend, you could use business services based on Web Services, EJBs, or many other technologies and still use the ADF binding layer to connect the back and frontend parts together.
Entity objects form the base that view objects are normally built on, and all data modifications go through the entity object. You will normally have one entity object for every database table or database view that your application uses, and this object is responsible for producing the correct SQL statements to insert, update, or delete data in the underlying relational tables. The entity objects help you build scalable and well-performing applications by intelligently caching database records on the application server in order to minimize the load that the application places on the database.
Like entity objects are the middle-tier representation of database tables and database views, associations are the representation of foreign key relationships between tables. An association implements a connection between two entity objects and allows ADF to connect data in one entity object with data in another.
JDeveloper is normally able to create associations automatically by simply inspecting the database, but in case your database does not contain foreign keys, you can build associations manually to let ADF know about the relationships in your data.
View objects and view links While you don't really need to make any major decisions when building the entity objects for the Proof of Concept, you do need to consider the consumers of your business services when you start building view objects—for example, what information you would display on a screen.
View objects are typically based on entity objects, and you'll mainly be using them for two purposes: One screen can use multiple view objects. If you have master-detail data, for example, departments containing employees, you create one view object for each master-detail level you wish to display on your screen for example, one department and one employee view object. If you need to look up a reference value from another table, you don't need to create a separate view object for this.
For example, an employee entity object might contain only the department number. If you want your view object to display the department name, you need to include the department entity object in the view object in order to retrieve it.
The LOV view objects are used for drop-down lists and other selections in your user interface. They are typically defined as read-only, and because they can be reused, you can define them once and re-use them everywhere you need a drop-down list on a specific data set. View links are used to define the master-detail relationships between the view objects and are typically based on associations again, they are often based on foreign keys in the database.
In this case, you create two view objects connected by a view link. The right-hand side illustration shows a situation in which you wish to display all employees together with the name of the department they work in. Application modules Application modules encapsulate the view object instances and business service methods necessary to perform a unit of work. Each application module has its own transactional context and holds its own database connection.
This means that all of the work a user performs using view objects from one application module is part of one database transaction.
However, there is no limit to the amount of functionality you can put into one application module— indeed, it is possible to build a small application using just one application module. Application modules for Oracle Forms If you come from an Oracle Forms background and are developing a replacement for an Oracle Forms application, your application will often have a relatively small number of complex, major forms and a larger number of simple data maintenance forms.
You will often create one application module per major form and a few application modules, each of which provides data, for a number of simple forms. If you wish, you can combine multiple application modules inside one root application module. This is called nesting and allows several application modules to participate in the transaction of the root application module. This also saves database connections because only the root application module needs a connection.
JSF is a component-based framework for building web-based user interfaces that overcome many of the limitations of earlier technologies such as JavaServer Pages JSP. In a JSF application, the user interface does not contain any code but is built from the configurable components of a component library instead. It had long been clear to web developers that in a web application, you cannot just let each page decide where to go next—you need the controller from the MVC architecture.
Various frameworks and technologies have implemented controllers both the popular Struts framework and JSF have this , but the controller in ADF Task Flows was the first one capable of handling large enterprise applications. An ADF web application has one unbounded task flow where you place all of the publicly accessible pages and define the navigation between them.
This corresponds to other controller architectures such as Apache Struts. The user can enter an unbounded task flow on any page. However, ADF also has bounded task flows, which are complete, reusable mini applications that can be called from an unbounded task flow or from another bounded task flow. A bounded task flow has a well-defined entry point, accepts input parameters, and can return an outcome back to the caller.
For example, you might build a customer management task flow to handle customer data. In this way, your application can be built in a modular fashion—the developers in charge of implementing each use case can define their own bounded task flow with a well-defined interface for others to call.
The team building the customer management task flow is thus free to add new pages or change the navigation flow without affecting the rest of the application.
ADF pages and fragments In bounded task flows, you can define either pages or page fragments. Pages are complete web pages that can be run on their own, while page fragments are reusable components that you can place inside regions on pages. A traditional web application consists of pages—when the user interacts with the application, the whole browser window will redraw, thus showing the next page of the application.
In a Rich Internet Application, on the other hand, you will have a small number of pages possibly only one and a larger number of page fragments. These page fragments will dynamically replace each other inside a region on an application page, so the user sees only a part of the page change. If you choose this technique, your application will seem more like a desktop application than a traditional web application.
These are containers for other components and control the screen layout. Often, multiple layout components are nested inside each other to achieve the desired layout. These are the components that the user interacts with to create and modify data.
Data components range from fairly simple components, such as an input field or a checkbox, to very sophisticated components, such as an ADF table. These are the buttons and links used to perform actions in an ADF application. Content of a Proof of Concept The most important part of the Proof of Concept is that it goes all the way through the mountain, or in application development terms, all the way from the user interface to the backend data service and back.
However, if for some reason, you decide to not use ADF Business Components or you want to base your business components on something other than relational tables, things get more complicated. In this case, you will need to demonstrate that you can retrieve data from your data service, display it on the screen, modify it, and successfully store the changes in the backend data service. If that's the case, your Proof of Concept user interface needs to demonstrate the use of these special components.
There might also be other significant requirements you need to consider. Your application might have to use a legacy authentication mechanism such as a database login. Another possibility is it might have to integrate with legacy systems for authorization or customization, or you might need to support accessibility standards allowing your application to be used by people with disabilities.
If you have these kinds of requirements, you have to evaluate the impact on your project if you can't meet them. If they are critical to your project's success; you need to validate them in a Proof of Concept.
Making the technology work The ADF technology obviously works. Hundreds of organizations have already followed Oracle's lead and built big enterprise applications using Oracle ADF. It is very straightforward to use the ADF framework with relational tables; the framework handles all of the boring object-relational mapping, allowing you to concentrate on building the actual application logic.
You are likely to inherit at least some of the data models from a pre-existing system, but in rare cases, you will be building a data model from scratch for a brand new application. JDeveloper does allow you to build data models, but Oracle also has other tools for example, SQL Developer Data Modeler that are specialized for the task of data modeling.
Either way, the ADF framework does not place any specific restrictions on your data model—any good data model will work great with ADF. But your requirements are special, of course.
Nobody has ever built an application like the one you are about to build—that's the essence of a project: After all, if you didn't need anything special, you could just pick up a standard product off the shelf. So, you need to consider all of your specific requirements to see if ADF can do it. ADF can still do it. The ADF framework is immensely powerful as it is, but it also allows you to modify the functionality of ADF applications in myriad ways to meet any conceivable requirement.
Building an enterprise application is a major undertaking for your organization, and you want to prove that your application can meet the requirements. Determining the development speed The development speed of a task mainly depends on three factors: The size and complexity of the task is given by your requirements.
It would be a rare project where all of the requirements are exactly known at the beginning of the project, but if you have a set of detailed requirements, you can make a good estimate of the project's size and complexity. The speed of development will be the greatest unknown factor if ADF is new to you and your team. Using your previous development tool for example, Oracle Forms , you were probably able to convert your knowledge of project size and complexity into development effort, but you don't yet know what your development speed with ADF will be.
Your relationship with your development tool will go through a number of phases— not unlike a romantic relationship. Using the terminology of some of the countless relationship coaches on the Internet, we can identify three phases of a relationship: You will be building the types of functionalities illustrated in the tool tutorials—fairly simple stuff that the tool supports really well.
After this stage comes power struggle. You want to implement some specific functionality and the tool simply refuses to cooperate. During this stage, your development speed drops and your frustration rises…. Assuming that the relationship between you and your tool survives this phase, you can move on to the co-creativity stage. This is where you understand the tool: During this stage, your productivity recovers to the initial level and continues to grow to a higher and higher level.
However, if you do this, you must be aware of the period of lower productivity before you start climbing up with your full productive development speed. Getting help Many developers working on their own find that after a few weeks of infatuation, the power struggle phase can take up to months before productivity starts to climb again. If you want to move forward faster, you need to break out of your isolation and get some help.
In my experience, typical classroom training is not enough to move through the struggle phase. Try to find an experienced ADF developer who can both teach and offer mentoring and support you on your way to mastering ADF.
Also, use the Oracle Technology Network forums available at otn. The Proof of Concept deliverables The outcome of the Proof of Concept is not an architecture in the form of boxes and arrows on a PowerPoint slide. David Clark from the Internet Engineering Task Force said, We believe in running code—and that's what the Proof of Concept should deliver in order to be credible to developers, users, and management: Additionally, it is a good idea to record the running Proof of Concept application with a screen-recording tool and distribute the resulting video file.
This kind of demo tends to be watched at many places in the organization and gives your project visibility and momentum. A DMC is a specialized travel agency, sometimes called an "incoming" agency, and works with clients in the country where it is based. But if you manage to qualify for a company-paid trip to some exotic location, your company is likely to engage the services of a DMC at the destination.
If you have ever participated in a technology conference, a DMC will normally be taking care of transfers, dinners, receptions, and so on. The system that DMC Solutions is selling today is based on Oracle Forms, and the sales force is saying that our competitors are offering systems with a more modern look and a more user-friendly interface. Your mission, should you choose to accept it, would be to prove that ADF is a valid choice for a modern enterprise application, and if so, set up a project to build the next generation of destination management software the XDM project.
The rest of this chapter shows you how to build the Proof of Concept application implementing two use cases. You can simply read through it to get a feel of the tasks involved in creating an ADF application, or you can use it as an ADF hands-on exercise and perform each step in JDeveloper on your own.
These two use cases represent the application's basic functionality the ability to search and edit data , as well as a graphical representation of time data, something new that wasn't possible in Oracle Forms. UC Task Overview and Edit The UC Task Overview and Edit screen allows the user to search for tasks by the responsible person, program, or a free-text search, as shown in the following screenshot. Data can be updated and saved back to the database.
This term is used because British English makes a distinction between "programme" a set of structured activities and a "program" something that runs on a computer. The screen is not a dialog box, but uses OK to accept changes and save data, and Cancel to cancel any changes and revert to the saved data.
For simplicity, we will not implement the application menu, but just have a button labeled Timeline that invokes UC instead. Again, we will not have a menu, just a button called Overview for returning to UC Data model The destination management system starts with events, such as "Oracle OpenWorld ". One person is responsible for each programme. Within a programme, there will be a number of tasks that point to standard elements from the element catalog.
Examples of elements could be a limo transfer, a dinner, an excursion, and so on. Each task will be assigned to exactly one person. DATE This script also contains some anonymous data. JDeveloper is freely available for download and use from the Oracle Technology Network otn. If you don't already have a free Oracle account, you will have to create one.
The illustrations in this book use JDeveloper 12c, Version If a later version of JDeveloper is out by the time you read this book, use that instead. The basics of ADF development have not changed over the last couple of years, so you should be able to immediately find the dialogs and options you are looking for.
In addition, since Oracle has built a very large application based on JDeveloper, you can be sure that there will be a simple migration path moving forward. The following steps describe how to create a workspace for an ADF enterprise application—if you want to use this chapter as a hands-on exercise, use the suggested values in each step: Start JDeveloper.
Navigate to File New Application. Click on OK.
Give your application the name, XdmPoC, choose where to put it in the filesystem you can leave the default—just note where your projects are stored , and provide an Application Package Prefix. Use your organization Java prefix followed by your project abbreviation for the Proof of Concept, use com.
Java package prefix Traditionally, package names start with your organization's Internet domain with the elements reversed. So, if your company domain is mycompany. However, some organizations such as Oracle feel that their names are sufficiently unique, and they don't need to include the first com. If your organization has ever used Java earlier, your Java package prefix has probably already been chosen and documented somewhere.
Ask around. You can simply click on Next through the rest of the wizard. This will create a new application containing the two projects, Model and ViewController. In the main window, JDeveloper will show you the application checklist, as shown in the following screenshot: The application checklist actually gives a great overview of the steps involved in building an ADF application, and if you click on the little triangles to expand each step, you'll see links to the relevant JDeveloper functionality for that step, together with links to the relevant places in the documentation.
It even has checkboxes that you can check as you complete the different phases in developing your ADF application. The preceding screenshot shows the most commonly used panels, but you can toggle each of the many panels on and off using the Window menu. If you have not worked with JDeveloper earlier, please take a moment to familiarize yourself with the typical panels shown in the preceding screenshot: This important window shows the detailed structure of the component you are working on.
For example, when you are working on a page in the main window, the Structure window will show a tree with all of the components on the page. The Components window will also appear as a separate tab in this location when editing a page, allowing you to select components to add to the page. You can rearrange these panels to your liking by grabbing the tab at the top of each panel and dragging it to a new location, or even dragging it out of JDeveloper to make it a floating window.
This can be useful if you have multiple monitors. If you accidentally change the layout to something you don't like, you can always navigate to Window Reset Windows To Factory Settings. There are literally hundreds of preferences to set, most of which will not mean anything to you yet. The defaults are mostly fine, but feel free to change the settings. The Help section explains the various options well.
These settings tell JDeveloper to place different types of business components in separate Java subpackages for an easier overview when you have many components.
These are just defaults to create a good starting point. As you build your application, you might decide to move your business components and classes to other packages, and JDeveloper makes this safe and easy. If you're using Microsoft Windows, this value is probably set to a default Windows character encoding.
The description in this book is fairly brief and assumes that you have worked a little bit with ADF earlier, for example, by going through a basic ADF tutorial on the Oracle Technology Network website otn.
You can find links to some relevant tutorials on the book companion website www. For the Proof of Concept, we will leave all business components in the default location: However, when building a real-life enterprise ADF application, you will be splitting up your application into multiple application workspaces and using ADF Libraries to compile these into the master application. Working with smaller workspaces enforces modularity in the code, makes it faster for the developer to find what he's looking for, allows faster checkouts from source control, and JDeveloper also runs faster and better when it is not handling thousands of objects at the same time.
We'll return to the proper structuring of workspaces in Chapter 3, Getting Organized. Creating a connection As you might have noticed from the application checklist, the first step after Plan your Application is to create a connection to the database schema where your application tables reside. Each application workspace has its own connections, but you can also create general connections in JDeveloper that you can later copy into your applications.
In the Create Database Connection dialog, give your connection a name xdmpoc and provide a username, password, and connection information. If you perform a default Oracle 12c database installation and call your database orcl, you get a pluggable database called pdborcl.
If you are running against a remote database, ask your database administrator for connection information. Click on Test Connection to check that you have entered everything correctly and then click on OK, as shown in the following screenshot: To start building, right-click on the Model project, choose New from the context menu, and then click on Entity Object.
Make sure that you select the Model project before you start creating business components. The Initialize Business Components Project dialog appears the first time you create a business object. Then click on OK. This book assumes that you use an Oracle database, and the above selections are recommended for this. Click on the Help button in the dialog for more information on these choices. You can also click on Browse to query the database. Then click on Next. Naming standards When you start your enterprise application development project in earnest, you need naming standards for everyone to follow.
We'll return to naming standards in Chapter 3, Getting Organized. In step 2 of the wizard, just click on Next to create entity object attributes for every column in the database.
In ADF, there is no overhead at run time for having attributes for unused columns—when the ADF framework issues a SELECT statement to the database, it retrieves only those attributes that are actually needed by the view object.
One thing that often needs to be changed here is the type for primary key columns. If the table has a numeric ID column and a database trigger that sets this value when the record is created in the database, you need to set the Type to DBSequence.
Do this for the PersId attribute, as shown in the following screenshot: Notice that the ADF framework has now changed the values in the right-hand side of the dialog box: Updatable is now set to While New, and in the Refresh After box, the checkbox for Insert is now checked.
This means that the entity object will automatically retrieve the primary key value created by your trigger. You don't have to make any changes in steps 4 through 6, so you can simply click on Finish here to close the wizard and create your entity object. For the Proof of Concept, repeat the procedure discussed earlier and create the following entity objects: Building associations for the Proof of Concept When you have created the entity objects, you will normally find that JDeveloper has automatically discovered the relationships between them based on the foreign keys defined in the database.
The missing link The ADF framework needs to know about the relationship between entities. In case you have to build an ADF application on an existing database where relations between data records are not implemented as foreign keys in the database, you can define the associations in JDeveloper. This allows you to determine both the data you need to present and the value lists you'll need.
Looking at the Task Overview screen UC , we see that all data is at the same level no master-detail level , so we will just need one Tasks view object to display the data. Additionally, we'll need three value lists: As data is presented graphically, it's not immediately obvious whether the data contains any master-detail relationship. To determine if that is the case, consider how you would display the same information in ordinary fields and tables.
Such a screen might show: Creating view objects for value lists To create view objects for persons, right-click on the Model project and navigate to New View Object. It's a good idea to give your view object a name that indicates its intended usage as a list of values.
For the list of persons, use the name PersonLOV. Leave the data source at Entity Object. Since ADF 11g, the benefit of caching those entity objects outweighs the slight performance benefit from executing SQL directly. The recommendation is, therefore, to access data through entity objects always. You can remove the checkmark in the Updatable box since we will only be using this view object for the drop-down list, as shown in the following screenshot: In step 3 of the wizard, move the fields you want to the right-hand side—in this case, we just need Initials.
Note that the primary key attribute will always be included, as shown in the following screenshot: Then, click on Finish to create the view object. Repeat this procedure to create the other two value list view objects, which are as follows: You'll notice that we need fields for date and time, text, start where, flight number, end where, number of passengers, and service.
In step 2 of the wizard, choose the Task entity object and move it to the right-hand side. As we will actually be updating data through the AllTasksVO view object, we leave the check mark in the Updatable checkbox.
In step 3, shuttle the following fields to the right-hand side: Then click on Next to get to Bind Variables step 6. You should never simply concatenate values into an SQL statement; if you do, the database can't tell that it already knows the SQL statement and will waste time parsing it again, and a malicious user could potentially insert extra statements into your SQL.
Looking at the search box at the top of the screen sketch, you can see that we need to limit the tasks displayed by responsible person, programme, and text. Use the New button to create three bind variables called pResponsible, pProgramme, and pText all of them of type String. You can leave the other settings in this step of the wizard at their default values.
When you're done, click on the Back button to return to step 5 of the wizard and add a WHERE clause that uses the bind variables. It should look similar to the following code: If you do not get the Query executed successfully message, fix your SQL. In this case, we allow null values for the bind variables, so the SQL statement has to contain an OR branch handling this case. We are converting both the database TEXT column and the pText bind variable to upper case to achieve case-insensitive matching.
We are also concatenating a wildcard character before and after the parameter value to search for occurrences of the search text anywhere in the database value. Read about named view criteria and the associated af: When you click on Finish, the AllTasksVO view object is created and appears in the application navigator.
You might remember from the page layout illustration that Service was rendered as a drop-down listbox. Double-click on the AllTasksVO view object to edit it and choose the Attributes subtab on the left-hand side.
Choose the ElemKey attribute and then select the List of Values tab at the bottom of the view object window. Click on the green plus sign to bring up the Create List of Values dialog, as shown in the following screenshot: In this dialog, click on the green plus sign to add the List Data Source.
Since we don't want to display the actual key value ElemKey to the user, choose the UI Hints tab and move the Description attribute to the right-hand side box. The Attributes tab also allows you to define some hints to the user interface components about rendering the component. Click on the StartDate attribute and choose the UI Hints tab at the bottom of the view object window.
Click on the remaining elements and set the label text, referring to the user interface sketch for UC Format is only used for date and number objects. Taking a hint The control hints defined here are just hints.
When building the user interface, these will be the default, but you can still decide to use another label text or format when you use the view object on a page. For simplicity, we are hardwiring labels into the application—in a real-life application, texts should go into separate resource bundles.
Refer to Appendix, Internationalization, for more information. Building an application module for tasks To create an application module for tasks, right-click on the Model project and navigate to New Application Module.
Name the application module as EditTaskService. This is all you need to do, so you can simply click on Finish to close the wizard. Note that the view object instances on the right-hand side get the name of the view object with a number appended to them by default. The instance name is part of the contract between the business service and the user interface—if you want to change it, do so before anybody starts building the user interface.
The reason for this default is that it is possible to have several view object instances based on the same view object in an application module.
Now, you can verify that your application module works the way you expected it to. In the Applications window, right-click on the EditTaskService application module node the icon that looks like a little suitcase and choose Run from the context menu.
This will start the Oracle ADF Model Tester where you can work with all of the view objects that are part of your application module. Whenever your page doesn't run the way you expected, always use the ADF Model Tester to determine if the error is in the frontend or the backend part of the application. Double-click on the AllTasksVO1 view object instance. A pop-up dialog appears, allowing you to assign values to all the bind variables defined in the view objects.
You should see the data in the AllTasksVO view object, as shown in the following screenshot: Here, you can page through the existing data, as well as insert and delete rows, using the green plus and red cross symbols.
Click on the Edit Bind Variables button to the right of the toolbar, with the little pencil icon to change bind variable values and notice how the data is filtered. We already have a view object showing persons, but this view object only contains the initials because it was intended for the Persons drop-down list in UC We could create a new Persons view object for UC; however, we'll change the existing view object instead.
First, you need to change the name of the view object from PersonLOV to PersonsVO to reflect that it's no longer just used for a list of values. Changing the name or package for existing objects is called refactoring, and JDeveloper makes this easy.
JDeveloper will change the name of the object and automatically update all of the references to it, as shown in the following screenshot: To add these, open the view object by double-clicking on it and choose the Attributes subtab. Click on the little triangle next to the green plus sign above the attributes and choose Add Attribute from Entity, as shown in the following screenshot.
Don't just click on the plus sign—you need to select the little triangle to get access to the Add Attribute from Entity menu item. Then, select the new FirstName attribute, select the UI Hints tab at the bottom of the view object window, and set a Label.
Repeat this procedure for the LastName attribute. Next, create another view object, giving it the name ScheduledTasksVO. In step 2 of the wizard, move the Task entity object to the right-hand side. As we won't be updating tasks either, you can remove the checkbox in the Updatable field here. In step 3 of the wizard, you only need to select the StartDate and EndDate attributes—note that the TaskId primary key attribute is automatically added. In step 5 of the wizard, we need to add a WHERE clause so that the view object will only show tasks with both, a start and an end date.
Since there is a master-detail relationship between persons and tasks, we also need to create a view link. Right-click on the Model project and choose New View Link. Name your view link PersonsTasksLink. In step 2 of the wizard, we need to define the relationship between the two view objects.
Leave the Cardinality selection at Then, click on Add. You can see the source and destination attributes added at the bottom of the dialog box, as shown in the following screenshot: One lump or two? You want to modularize your application so that each piece of functionality is completely developed and delivered by one team.
This means that each subsystem gets its own application module. When you put together the final application, you can choose whether you want each subsystem and each application module to have its own transaction and database connection or whether they should share the transaction context.
We'll return to the discussion of the proper number of application modules in Chapter 3, Getting Organized. If you choose the view object as a child of another view object, the ADF framework will automatically implement the master-detail relationship; the view object will only display the records that are children of the current record in the parent master view object.
If you choose the view object on its own, it will not have any relationship to the master view object and will simply display all child records. Then, click on Finish to close the wizard.
Many inner libraries have been used by outer applications even that they do not suppose to do that, but there was no way to restrict that. They divided JDK into more than 90 separate modules. Each module encapsulates its own piece of functionality of the Java runtime library. The picture above represents the dependencies between the modules.
The most important one is the java. It represents the most basic classes of the language, like streams, strings, and objects. Since this module is essential, all other modules depend on this library. Here, we see a more complex graph about the different libraries and how they connect to each other.
The ones with names starting with java indicate that these are part of the Java SE specifications. In the dependency graph above, you can also see two modules in blue; these do not start with java but jdk. These are JDK-specific.
You may notice that all arrows are pointing down. This means that there are no circular dependencies. Hence, it has very clean modularization. However, it is isolated into its module. This means that unless your application has a dependency on java. Another module in this graph you may be more familiar: Java. It contains all the swing GUI toolkits of the Java platform.
This is due that the fact a module can explicitly expose some of the packages and strongly encapsulate other packages. As I mentioned earlier, there are many internal implementations in classes in the JDK that need to be public because it is used among different packages, but at the same time, they should not be used outside of JDK. These later ones are encapsulated. You do not need to scan and load all the classes that the rt. Easy Deprecation Having clearly separate modules also helps deprecation.
The idea is that, at some point, a module can be marked as deprecated. Every application that uses that module should look to another solution.
After that, in the next major release, it can be removed from the JDK. It is already happening because in Java 9, the java. Future Proof The deprecation example is true from the other way as well. It is much easier to ship new features to the language. They can add incubator modules, and if it is stable, it can be converted to a real module with the next major release. There is an example as well as the jdk.