C H A P T E R 3
Core APEX vs. Enhanced APEX
An important strategic decision must be made at the beginning of an APEX project. The team must decide whether it will use the core APEX product exclusively or whether it will enhance the APEX development environment by adding support technologies that are not built into the APEX framework. This chapter explores the pros and cons of both alternatives so that you can pick your strategy based on all of the considerations. This is not a trivial choice; it has significant impact on all aspects of an APEX project.
Using the core APEX product directly supports two Agile principles, “ customer satisfaction by rapid delivery of useful software” and “ simplicity.” Using enhanced APEX tends to support the Agile principle of “continuous attention to technical excellence and good design.” Balancing these two potentially conflicting principles requires intimate knowledge of your software development culture and good judgment.
Strategic Ways Forward
There are four strategic ways forward in an APEX environment. You can do the following:
- Use the core of APEX exclusively
- Enhance APEX with supporting technologies
- Use the core of APEX now and trust that future APEX versions will provide the enhanced functionality that you and your users desire
- Use another technology
Over the last six years, I have had good luck with using the core of APEX exclusively. My users were inside departments, both public and private, and they were content with the default functionality that came with the early versions of HTMLDB and then the newer versions that were rebranded as APEX. My users were, by and large, more interested in getting their applications up and running in production sooner than later; therefore they opted for fast delivery and lower costs over enhanced functionality.
There are legitimate cases, however, in which enhancing the user interface with supporting technologies is highly desirable despite the impact on schedule and cost. One very large client opted to duplicate an existing graphic user interface (GUI) that was built using an older technology. The client felt that the time and cost of building a custom APEX theme and adding some significant JavaScript extensions to APEX was more cost-effective than re-training several thousand users who were scattered around the globe in several different cultures. The project was a success, and the custom theme and the well-crafted JavaScript libraries were reused to great advantage. I believe, however, that much of the JavaScript will be dropped when the client eventually converts the application from APEX 3.2 to APEX 4.x. Another legitimate argument for enhancing APEX with JavaScript technologies is performance. Moving user interaction logic from the server to the browser reduces the load on the server’s CPU and may avoid the cost of an additional CPU license for your Oracle database. Another case for enhancing APEX can be made for applications for which users have very demanding and specific requirements that are not easily supported by the core APEX browser functionality.
If you have patient users, you can develop applications using the core APEX functionality and then wait for newer versions of APEX to supply the desired enhancements. This strategy demands that you aggressively refactor your applications every time you install a new version of APEX to take advantage of its new features.
Occasionally you will run into an application, an environment, or a group of users who need functionality that cannot be satisfied by APEX in a cost-effective manner. In this case, you will need to consider using an alternative technology. However, as APEX matures, the need for this strategy is diminishing.
The following sections explore these strategies in more detail.
Use Core APEX Exclusively
“ Simplicity” is one of the key principles of Agile software development. Using the core APEX framework exclusively is an elegant way of applying the Agile principle of “ simplicity” to your development environment. Quickly building useful software that has real value to the customer is another key principle that APEX fully supports with its rapid application development (RAD) environment.
Simplicity and speed stem from APEX’s reliance on wizards that walk developers through well-defined declarative steps to create almost all of a web application’s components. The APEX Application Builder (see Figure 3-1) makes all of the common components visible at one time. Every component region has a Create button in the upper right corner, which launches the appropriate wizard. In all cases, the wizards create a functional component that works reliably; usually only minor changes are needed after the initial creation. In fact, when the developer takes the time to use the User Interface Defaults to configure the database column attributes, many sub-components like validations are created automatically by the APEX engine. Generally, it takes under a minute to step through a wizard that creates a component.
Figure 3-1. Application Builder
I have been working with APEX for over six years, and every once in a while I need to step back from the trees to contemplate the forest. Core APEX delivers a lot of useful functionality that experienced APEX developers tend to take for granted. I, for one, must remind myself periodically of the bad old days when I had to write a lot of code to get simple things to work when I worked with other technologies. Core APEX eliminates almost all of the coding that is required to connect a GUI to a database; therefore you free up time for more important things like coding an application’s business rules.
Six years ago, my team and I tried to document all of the possible options and permutations that are created when you mix and match the wizards. We failed. We found that the combinations were almost infinite, so we limited ourselves to a small subset of combinations that seemed to work well for us at the time. We documented these combinations in our team’s Rules and Guidelines document (see Chapter 7). Over time, as we learned more about APEX and as new APEX versions became available, the combinations that we used evolved and improved. This evolutionary process illustrates a healthy application of Agile’s principles of “ Continuous attention to technical excellence and good design” and “ Regular adaptation to changing circumstances.”
The following sections describe, at a high level, many of the core APEX components that are created by the wizards. The purpose of these sections is to show you the many options that are available to you when you use the core APEX functionality. The detailed usage of these options is well documented elsewhere in a number of Apress books.
Pages
Web pages are the fundamental building blocks of an APEX application. They are containers that hold regions, buttons, items, business logic, and navigation links. Components that are shared by many pages are also visible; examples are tabs, lists of values, breadcrumbs, and lists.
The page creation wizard is actually a grouping of related wizards that create a rich variety of pages that satisfy most business requirements. The APEX 4.x page wizards are as follows:
- Blank Page
- Multiple Blank Pages
- Report
- Interactive Report
- Classic Report
- Report on Web Service Result
- Wizard Report
- Form
- Form on a Procedure
- Form on a Table or View
- Form on a Table with Report
- Master Detail Form
- Tabular Form
- Form on a SQL Query
- Summary Page
- Form on Web Service
- Form and Report on Web Service
- Plug-Ins
- Items
- Regions
- Dynamic Actions
- Page Processes
- Authentication Schemes
- Authorization Schemes
- Chart
- Map
- United States of America
- World and Continent Maps
- Europe
- North America
- South America
- Asia
- Africa
- Oceania
- Custom Maps
- Tree
- Calendar
- Easy Calendar
- SQL Calendar
- Wizard
- Data Loading
- Feedback Page
- Login Page
- Access Control
The purpose of the foregoing list is to show you how much choice you have when creating web pages using only the core of APEX. The wizards create the pages together with the appropriate regions, items, buttons, tabs, breadcrumbs, DML processes, and validations.
Launching the Create Page Wizard is simple and fast (see Figure 3-2). The individual wizard steps are broken down into individual bite-sized pages that each contain a small number of related items (see Figure 3-3). In this case, there are eight individual wizard pages that are listed on the left. Stepping through the wizard is quick, simple, and accurate.
Figure 3-2. Launching the Create Page Wizard
Figure 3-3. Wizard steps to create a form on a table or view
Regions
Regions, like pages, are containers for other components. You create regions on pages where additional functionality is required that was not created automatically by the page creation wizards. APEX 4.0 introduced the concept of nested regions, a useful layout option. The region wizard options are summarized here:
- HTML
- HTML
- HTML Text (with shortcuts)
- HTML Text (escape special characters)
- Multiple HTML
- Report
- Interactive Report
- Classic Report
- Web Service Result
- Wizard Report
- Form
- Form on a Table or View
- Tabular Form
- Form on a Procedure
- Form on a Table with Report
- Form on a SQL Query
- Display Only on Exiting Items
- Master Detail Form
- Form on Web Service
- Form and Report on Web Service
- Plug-Ins
- Chart
- Flash Chart
- HTML Chart
- Map
- United States of America
- World and Continent Maps
- Europe
- North America
- South America
- Asia
- Africa
- Oceania
- Custom Maps
- Tree
- Calendar
- Easy Calendar
- SQL Calendar
- Breadcrumb
- PL/SQL Dynamic Content
- URL
- Region Display Selector
- Help Text
Mixing and matching pages and regions allows you to build web pages that contain a great deal of functionality. You probably noticed that there is a great deal of overlap between pages and regions. This is not surprising because very often the page wizards simply create a page together with an appropriate region. The region wizards allow you to add a mix of regions to a single page.
Buttons
Most buttons are created automatically by the page and region wizards. However, it is common to add buttons to a page to help with navigation or to launch business processes. The core APEX button creation wizard supplies two types of buttons:
The positioning of region buttons is controlled by a theme’s templates. The positioning of buttons that are displayed among a region’s items is controlled by the developer, who simply adds the button to a page in the same way as adding individual items like text boxes and select lists (see Figure 3-4). The fundamental difference between the two button types is found in their display properties. In this example, the Cancel button is displayed in the region template position that is defined by the #CLOSE# template substitution variable (see Figure 3-5). The Send Email button’s position is defined by its sequence number and its HTML positioning properties Begin on New Line, Field, ColSpan, and Row Span (see Figure 3-6).
Figure 3-4. Buttons are in region positions or among the page items.
Figure 3-5. Display properties for a button in a region position
Figure 3-6. Display properties for a button among the page items
Items
APEX items are components that are equivalent to controls and widgets in other technologies. Core APEX gives you the following:
- Check Box
- Date Picker
- Display Image
- Display Only
- File Browse
- Hidden
- List Manager
- Number Field
- Password
- Plug-Ins
- Popup List of Values
- Popup LOV
- Color Picker
- Text Field with Calculator Popup
- Radio
- Rich Text Editor
- Select List
- Shuttle
- Stop and Start Table
- Text Area
- Text Field with Auto Complete
- Text Field
Some of the items, like Text Field, are relatively simple and primitive. Others, like the Shuttle and Rich Text Editor, are sophisticated and clearly illustrate the fact that good-looking and good-quality applications can be built by using only the core APEX product.
The Shuttle is a composite of multiple HTML components that would be time-consuming to assemble by hand (see Figure 3-7). The Rich Text Editor consists of a significant amount of JavaScript that you do not have to write (see Figure 3-8). The declarative nature of core APEX makes these sophisticated widgets relatively quick and easy to build and maintain. The words “sophisticated” and “quick” are important adjectives that apply to both the core APEX product and Agile software development.
Figure 3-8. Rich Text Editor item
Computations
Computations are used to assign values to components on a page. The Create Wizard gives you three choices:
- Item on This Page
- Item on Another Page
- Application-Level Item
Computations are fired when a page is either rendered or submitted.
Computations that are associated with application-level items are powerful. Application items are, in effect, global variables in an APEX application. When they are used wisely, they can help an end user to juggle multiple contexts at one time. For example, a user could be doing some data entry on a customer record and then gets interrupted by a phone call from a second customer. By using computations on two application-level items, the user is allowed to easily switch back and forth between the two customer records.
Processes
Processes are used to run business code on a page. Like computations, processes are fired when a page is either rendered or submitted. Your options are as follows:
- PL/SQL
- Reset Pagination
- Plug-Ins
- Session State
- Clear Cache for Applications (removes all session state for listed applications)
- Clear Cache for Current Application (removes all session state for current application)
- Clear Cache for Current Session (removes all state for current session)
- Clear Cache for Items (ITEM, ITEM, ITEM)
- Clear Cache for All Items on Pages (PageID, PageID, PageID)
- Reset Preferences (remove all preferences for current user)
- Set Preference to Value of Item (PreferenceName:ITEM)
- Set Preference to Value of Item If Item Is Not Null (PreferenceName:ITEM)
- Data Manipulation
- Automated Row Fetch
- Automatic Row Processing (DML)
- Web Services
- Form Pagination
- Send E-mail
- Close Popup Window
- Run On Demand Process
Some processes, like PL/SQL, are your windows into Oracle’s database processing world. PL/SQL processes are used to call both your custom PL/SQL code and Oracle’s incredibly rich set of database libraries. Your processing options are virtually unlimited. The simple example in Figure 3-9 could easily be running a few lines of PL/SQL code in the custom package or several million lines.
Other processes, like Session State and Data Manipulation, allow you to declaratively control the behavior of the APEX engine. The Session State processes are used to clear session state variables with a great degree of granularity. Data Manipulation processes declaratively encapsulate the code that creates, retrieves, updates, and deletes (CRUD) records in the database. The complex stuff, like record locking, is taken care of for you by the APEX engine.
APEX processes are an excellent example of Agile’s principle of “ continuous attention to technical excellence and good design.”
Figure 3-9. PL/SQL process
Dynamic Actions
Dynamic actions declaratively create JavaScript actions that control the behavior of items on a page. You choices are as follows:
- Standard
- Advanced
The standard wizard is a classic example of Agile’s simplicity principle. It is designed to quickly install JavaScript code on a page that, for example, does simple things like enable or disable items based on common situations in which an item is null or equal to a certain value. The standard wizard is designed to do simple things fast. Figures 3-10, 3-11, and 3-12 illustrate how easy it is to disable several page items based on the value of a text item.
The Advanced Dynamic Action Wizard follows the same steps as the standard wizard. The main difference is the much richer set of triggering events that are available; for example, you can trigger the advanced dynamic action with events like Change, Click, Double Click, Key Down, Mouse Button Press, and many more. The standard Show, Hide, Enable, and Disable actions are augmented with advanced actions such as Clear, Refresh, Set Focus, Execute JavaScript Code, Execute PL/SQL code, and several others. Dynamic actions, which were added to APEX in version 4.0, eliminate much of the hand-coded JavaScript that was added in earlier versions of APEX and HTMLDB.
Figure 3-10. Creating a standard dynamic action: When page
Figure 3-11. Creating a standard dynamic action: True / False Actions page
Figure 3-12. Creating a standard dynamic action: Affected Elements page
Validations
Validations do two things:
- They prevent bad data from getting into the database.
- They return meaningful messages to the end user.
APEX validations check for bad data when the user submits the page to the database. The validations fire in the database before the data is committed to the database. When an error is detected, control is returned to the user’s browser, where a message is displayed. Ideally, the message should be phrased in terms that the end user can understand. The message should help the user correct the problem so that the user can carry on with his or her work. If the problem cannot be fixed by the end user, then he or she should be directed to use the Feedback mechanism that is part of the Team Development module (see Chapter 6).
Validations can be done on a granular item-by-item basis, in which individual page items are checked. Page validations are used when relationships between multiple items must be checked; making sure a start date is before an end date is a simple example.
The options are as follows:
- Page Item
- Page
- SQL
- Exists
- NOT Exists
- SQL Expression
- PL/SQL
- PL/SQL Expression
- PL/SQL Error
- Function Returning Boolean
- Function Returning Error Text
- SQL
Branches
Branches control navigation to pages. They are often created automatically by the Create Page Wizards. You generally create your own branches when you add buttons and processes that must be linked to other pages.
Applications
The wizard that creates an application is incredibly powerful for creating the following:
- A starting point for a large application
- A complete simple application
In both cases, you step through a declarative process in which you choose what you want to create in the application. In APEX 4.1, the wizard’s hierarchy is as follows:
- Application
- Websheet
- Database
- From spreadsheet
- Upload file, comma separated (*.csv) or tab delimited
- Copy and paste
- Instant application
- As a copy of an existing application
- From scratch
- Based on existing application design model
- From scratch
- Add page
- Blank
- Report
- Form
- Report and form
- Tabular form
- Master detail
- Chart
- Select tabs
- No tabs
- One-level tabs
- Two-level tabs
- Shared components
- Copy shared components from another application, yes or no
- Authentication scheme
- Application Express
- Database account
- No authentication
- Theme
- There are 23 themes to choose from in APEX 4.1.
- Themes that are prefixed with an asterisk are IE 6–compatible (see Figure 3-13). This is handy for those of you still forced to support this archaic and difficult browser.
- From spreadsheet
The main take-away here is that the Create Application Wizard makes it possible for you to build a small and simple application in literally a few minutes. Remember, to you the developer, a small, simple application may seem trivial; however, to the business user, it can be seen as a valuable resource if it solves a business problem and contributes to the bottom line.
For large applications, I recommend using the Create Application Wizard to build a minimal application with only a single home page. This seed application then quickly grows as you use the various component wizards to add the required functionality.
Figure 3-13. The Application Wizard gives a visual preview of the available themes.
Use Enhanced APEX
The term “enhanced APEX” refers to APEX applications that use supporting technologies to supply functionality that cannot be achieved by using core APEX alone.
Here are a few words of warning based on my experience. Most of us come to APEX after working with other products like Oracle Forms, .NET, Visual Basic, Delphi, etc. I came to APEX after ten or twelve productive years using Visual Basic. At first, I crafted APEX designs that were comfortable for me based on my Visual Basic background. The designs turned out to be awkward to implement in APEX, and eventually I stepped back and started to learn how to use APEX in the way it was meant to be used. Over time I learned how to do things the “APEX way.” In the APEX world, plan “A” should always involve using the core APEX functionality where possible. This strategy is extremely Agile.
There are situations in which the core APEX functionality cannot meet your requirements and you must fall back on plan “B,” which involves adding some supporting technologies to your APEX framework. Some reasons to use enhanced APEX are as follows:
- Branding requirements
- Training issues surrounding change management
- Specific functionality requirements
- Performance
- Reporting
Impact of Enhanced APEX
Stepping outside of the core APEX functionality has significant impact on many aspects of your development environment (see Figure 3-14). The obvious impacts are increased cost and extended schedule. Enhancing APEX means adding more moving parts in the form of added technologies. More moving parts means that your team must learn new skills by taking the appropriate training or by hiring new personnel who already have the skills. As the team size grows, you must move from lightweight project governance to a heavier-weight governance model in order to keep the team organized. Risk goes up as you add more moving parts; there are more points of failure, which increases the required testing effort and makes debugging problems harder. In other words, the more you enhance APEX with supporting technologies, the less Agile you become (see Figure 3-15).
Figure 3-14. Effect of moving from core APEX to enhanced APEX
Figure 3-15. Enhanced APEX leads to less “Agility.”
The foregoing paragraphs might lead you to believe that I am against using enhanced APEX. This is far from the truth. When you have a legitimate requirement that lends itself to using enhanced APEX, then use it; but use it wisely. You must make realistic estimates of the effect it will have on your cost, schedule, team, and customer.
It is also useful to note that using enhanced APEX does not mean that you are not Agile. You can apply Agile software development principles to enhanced APEX projects; in this case, you will find that your Agile governance model will have to become a bit heavier so that you can keep the project under control.
Business Cases for Enhanced APEX
There are probably a very large number of reasons for using enhanced APEX. I will speak to a few that I have come across over the last few years.
Branding
Organizations often brand themselves. The appearance of their web pages is extremely important to them. APEX utilizes a theme/template model that uses Hyper Text Markup Language (HTML) and Cascading Style Sheets (CSS). HTML is used to define the content of an APEX web page, while CSS controls how it looks.
The core APEX themes tend to be conservative and suit internal-facing applications extremely well (see Figure 3-16). Enhancing an existing theme or developing your own requires knowledge of HTML and CSS, together with a good understanding of how APEX builds its themes and templates. The results can be quite remarkable (see Figure 3-17).
Figure 3-16. Core APEX themes create conservative business GUIs.
Figure 3-17. Enhanced APEX themes create branded GUIs.
Re-training
Many organizations have a long computing history that can date back to the 1950s or even a bit earlier. While I do not advocate building GUIs based on ancient dumb terminals, I do recognize the need to improve things without changing anything. This remark, of course, is facetious, but it does illustrate the crux of implementing change in an organization. Most people recognize the need for change, but they are comfortable with the status quo.
Years ago I was on a team that installed a new truck dispatch system in an open pit mine in Africa. The mine was replacing an older truck dispatch system that was not capable of moving forward. The mine personnel, being conservative in nature, were apprehensive about having to learn a new system. They relied heavily on a shift-end report for much of their daily work and communication. The mine manager, who was a very good people-person, asked us to duplicate the shift-end report precisely using the same header/footers, fonts, and layouts. The report did not fit our standard reporting infrastructure, so we coded it manually. The result was extremely positive; the mine personnel kept their shift-end report, which gave them a sense of continuity even though some other areas changed significantly.
The take-away here is simple. Enhance your template with a bright yellow “X” cancel button if that is what the users are using today; button design is merely cosmetic. Save your scarce training resources for the truly significant changes in the business processes.
GUI Functionality
Occasionally, users need something on a page that core APEX does not supply. In these cases, you can build the functionality by installing a JavaScript widget or an APEX plug-in (see Figure 3-18).
There are several open source JavaScript libraries available that contain handy widgets; two common ones are jQuery and Ext JS.
APEX plug-in technology is new as of version 4.0. Installing an existing plug-in into an APEX application is a relatively straightforward task. Creating an industrial-grade APEX plug-in is another matter; in fact, it is the subject of an entire book: Expert Oracle Application Express Plugins by Martin D’Souza (Apress, 2011).
Figure 3-18. Example of GUI functionality that core APEX does not supply
Performance
Core APEX performs most of its work on the server. Typically, a user makes a change on a browser web page and then submits it. The request goes to the server where the work is done, and the result is sent back to the browser. As the number of users and server requests increases, a point is reached where server performance is affected. The system architect has several choices to help make the application scale:
- Buy another CPU for the server
- Move some of the GUI work that is done on the server out to the browser via JavaScript
- Use AJAX to mitigate the amount of data on the page that must be refreshed
The capital and support costs of an Oracle CPU license must be weighed against the labor cost of coding the JavaScript and AJAX solution. This last point has been significantly mitigated with the introduction of dynamic actions in APEX 4.0. I expect that the need for hand-coded JavaScript and AJAX will diminish even further in future APEX versions.
Reporting
Core APEX does not have a built-in high-fidelity reporting engine. In this case, APEX developers are forced to look for solutions that are external to APEX.
The best technical choice is to use BI Publisher. BI Publisher works well with APEX and the learning curve is relatively shallow. Unfortunately, the capital cost is high and out of reach for many mid-sized organizations.
The alternatives to BI Publisher are several third-party reporting tools. Some are open source solutions; others charge a modest license fee. In all cases, the tools require more coding than BI Publisher; therefore, the cost trade-off boils down to capital cost vs. labor cost (see Figure 3-19). If you have a requirement for lots of reports and form letters, the labor cost involved in an open source solution will eventually exceed the capital and labor cost of BI Publisher.
Figure 3-19. Capital and labor costs of BI Publisher vs. open source reporting tools
Wait for Future APEX Versions
Waiting for core APEX to eventually provide the enhanced functionality that you need can be a viable strategy, providing your customers have patience. This strategy entails an aggressive refactoring strategy when you upgrade your instance from one APEX version to the next.
Oracle’s APEX development team has a good record of delivering new versions on an annual basis (see Table 3-1). Each new version that has been released contains significant improvements and enhancements, especially APEX 4.0, which contains dynamic actions and plug-ins. These two features have added a great deal of declarative browser-side control over the GUI.
The main risk that is associated with this strategy is that the enhancement that you need today might not be included in the next release of APEX. Mitigating this risk involves paying attention to Oracle’s statements regarding the future direction of APEX. Another excellent source of information regarding the future of APEX is the Oracle APEX developers themselves. Many of them regularly attend the annual Oracle Open World (OOW) and Kscope conferences. The Kscope conference is organized by the Oracle Development Tools User Group (ODTUG). The Oracle APEX developers are regular presenters at the conferences and are happy to speak with developers after their presentations and at the networking functions.
| Year | Version | Key New Features |
| 2001 | Flow Builder | Web development tool that was internal to Oracle |
| 2003 | HTMLDB 1.5 | First release to the public |
| 2004 | HTMLDB 1.6 | Themes, master-detail forms, page groups, page locking, multilingual capabilities |
| 2005 | HTMLDB 2.0 | SQL Workshop, graphic query builder, database object browser, session state protection |
| 2006 | APEX 2.2 | Packaged applications, APEX dictionary views, Access Control Wizard |
| 2007 | APEX 3.0 | PDF printing with BI Publisher, migration tool from MS Access, page and region caching |
| 2008 | APEX 3.1 | Interactive reports, runtime-only installation, improved security |
| 2009 | APEX 3.2 | Migration helper for Oracle Forms, security enhancements |
| 2010 | APEX 4.0 | Dynamic actions, improved charting engine, plug-ins, Team Development, websheets, RESTful web service support, enhanced interactive reports, improved Application Builder, better themes, APEX Listener |
| 2011 | APEX 4.1 | Improved error handling, use of ROWID, data upload, enhanced calendar, easier-to-use websheets, improved validations in Tabular Forms, extended plug-in functionality, improved dynamic actions, optimized HTML, improved support for mobile frameworks |
Use Another Technology
APEX is not the only web development tool in the world. There are many competing software development platforms that, like APEX, have strengths and weaknesses. There will be situations in which you will find that one of these competing platforms is better suited to the task at hand. Some of your options are as follows:
- Oracle Forms: If you have a large number of Oracle Forms applications in your shop, you might choose to stay with Oracle Forms and not bother converting to APEX or Oracle Application Development Framework (ADF). The risk here is succession planning; as your workforce ages, it will be hard to find young workers who are willing to use a development tool that appears static.
- Open Source: There are many open source products that can be used to build web-based applications.
- .NET: This tool is a popular development platform that is well supported by Microsoft.
- Oracle Application Development Framework (ADF): Oracle is investing a lot in its Java-based Fusion technologies. ADF is a key building block in the Fusion technology stack.
Bear in mind that tool choice is determined by both technical needs and the cultural environment in which the technology is used.
Summary
The core APEX development environment is a software development platform that is ideally suited to lightweight Agile software development practices. This tool, in the hands of a skilled and motivated team, is capable of incredible commercial success.
There are situations in which you will need to use enhanced APEX functionality by adding external tools that complement the core APEX environment. Enhanced APEX, given the increased number of moving parts, will increase the cost of your projects and affect your entire software development environment. You will find that your team, while still adhering to the core values and principles of Agile, will need to embrace some of the “heavier” Agile practices in order to control your projects.