After listening in on the AskTom Office Hours on this topic (make sure you also read the chat transcript), I had a few ideas for posts to help Forms developers transition to APEX, before my Forms knowledge gets too stale!
If you put the Forms & APEX IDEs together, it's not hard to see they're sown from the same cloth, so to speak.
 |
| Oracle Forms |
Navigator on the left, properties on the right, layout editor in them middle. All with similar behaviours (link to my videos from a while back)
 |
| Oracle APEX 5.1, with custom skin |
Before you begin...
The key thing to remember when transitioning from Forms to APEX is ... empty the cup.
Web behaviour changes some UX fundamentals, but it's an environment in which you should already be rather fluent. So forget about how you build applications in Forms, and think about how you want your website to behave.
Render vs Process
Forms renders the Form to the pixel from compiled source files, and you can show/hide elements on the canvas upon certain triggers firing.
A user visiting a URL in APEX will have their HTML page dynamically generated by PL/SQL, with a variety of conditions on components that decide if they're included in the render.
After the page is delivered to the browser, Dynamic Actions then respond to events that may happen on the page before the next page submit, which allows validation and processing of all the values on the page, or a page redirect, which just opens the target, leaving page data behind.
 |
| Render, Interaction, or Page Process? |
The behavioural difference to remember is that the database knows nothing about the values on the web page until you either
1) submit the page (Processing)
2) execute a PL/SQL dynamic action that submits page items to session state
 |
| PL/SQL Dynamic Action |
Many of your initial problems will probably relate to forgetting to submit/return these values.
Object Navigator Components
Triggers
Straight into a topic with conceptually different behaviours between Forms & APEX. Triggers in Forms drove pretty much everything. You're responding to some event that user has manifested in some way, often driven by moving the cursor.In a stateful environment, this behaviour is fine, and made Forms powerful. In the web environment, these triggers don't have much of a 1-to-1 translation, but the main analog here might be Dynamic Actions.
Many APEX pages might handle processing when you submit the page, so you may have validations, computations, and processes that fire, based on flexible conditions.
Interactive pages may have dynamic actions that respond to specific clicks, but not submit or refresh the entire page, just some of it. This reduces network traffic, and enables clever user experiences.
Alerts
Half your messages may come the process that fires when you submit the page, to be shown on the subsequent page.For instance, you could set the value of a common item P0_RESULT within your process, and display it as the success message using the
&ITEM. substitution syntax. |
| Page Process |
For Dynamic Actions interacting with the database, you may want to display the same style message.
Check out this example from Martin using the Supplied API.
Or for dialog behaviour where you control button naming, you might consider using a plugin such as Alertify or Pretius Enhanced Notifications.
 |
| Alertify Dynamic Action instance |
Attached Libraries
APEX takes care of the JavaScript and CSS libraries that support the Universal Theme, which supports all the components you need for flexible, dynamic applications.You can include your own JavaScript and CSS in several ways, mostly via the page attributes.
 |
| Page CSS attributes |
You can choose to add inline code, reference files that exist either in the database as a BLOB (#APP_IMAGES#), or sitting on the middle tier, typically served by ORDS, perhaps sitting on a Web Logic Server, prefixing the file location with #IMAGE_PREFIX#.
If you use a decent amount of custom JavaScript, you may wish to consider APEX Nitro.
Data Blocks
As a Forms developer, I remember spending a lot of time managing details of the data block, and they generally either broke up the page into chunks of data, or held buttons & hidden items.In APEX, you could say similar things about Regions. Each page is broken up into a bunch of regions, which could come in many forms. Check out the Component Templates available in the Universal Theme.
You can even construct master-detail relationships in APEX. There are no Relations to define, but relationship properties are set within the Region attributes.
Editors
I don't recall using Editors much in Forms, but if you want to handle large objects of the character variety, then you might consider the OraOpenSource plugin.Events
I don't remember using Events, but I believe they allow die-hard Forms developers to extend their application with JavaBeans.If there is something that APEX doesn't do out of the box, it will probably be worth looking to see if anyone has built a plugin for APEX to do so. Some of these are absolute crackers. Once I did a session on consuming plugins.
LOVs
I think the Record Group element is manifested as an LOV definition now, that can be shared in a number of places.An LOV in APEX is more coupled with the Item type. A radio group works well with a small handful of values, Select Lists for middle sized sets, and perhaps the Select2 or I really like the Modal LOV plugin for larger sets to be dynamically queried, while still mastering the keyboard entry.
Or you might even define your own modal page to fetch a value.
There is a native Popup LOV, but I don't like it.
Object Groups
Object Groups and Property Classes in Forms are little more vague than the rest, since this was the sort of thing that would be set up once in a blue moon, utilised many times.I think a comparison for grouping objects in APEX might be item plugins, possibly project specific.
Or maybe blueprints.
Parameters
Page Items are populated between pages to pass information to the next page, such as the selected record in a report. |
| Declarative Page Target |
Larger forms with a number of items are generally submitted as a whole, where the page process handles the data, and branches to the next page.
These values can be protected from URL tampering by session state security, at item, page, and application levels, often by default.
Popup Menus
I've seen explorations of contextual popup menus here, and here.The APEX team have implemented them within the Page Designer - my favourite is the duplicate option.
Program Units
When I used Forms, the general mantra was to keep code out of item/block level events, and manage packaged procedure calls from within program units.But we've all seen Forms written with a spectrum of best practices applied. This is where many of the performance problems could lie, especially poorly used post-query triggers.
For Forms to APEX migration projects, this is probably where most of your gold lies - all the business rules you want to keep. Depending on how well the application is written, you might get to re-use a lot of it, but in my experience, few Forms projects used SmartDB concepts.
If you're aiming for a certain % of re-use, don't aim too high. The code in here can be good guide for the developer in refactoring behaviour, but the APEX page(s) could end up looking and behaviour different to what you had in Forms, if only because you're now in a browser. Thought it could be because you've reviewed the business process since the Form was written 2 decades ago, or you've replaced a lot of the keystrokes with button taps.
Property Classes
Property Classes in Forms allowed the developer to utilise common attributes among each instance of a component.In APEX we can define User Interface Defaults in the data dictionary, so that each time items or reports are created for specific tables or columns, the same features are applied by default.
As for the style of the application, classes could be applied to components that carry a particular look & feel. The Universal Theme has a default skin that can be reconfigured declaratively.
Record Groups
Record groups where just the SQL component of the LOV.Head to an application's Shared Components, then locate LOVs. They can be dynamically driven by a SQL query, or be statically defined. Static definition allows a variety of conditions to be applied to each entry.
These LOVs can then be associated with Items such as Radio Groups & Select Lists, or with a column in a report, to translate a code to a label.
Reports
Reporting in APEX is a deep rabbit hole. Conceptually, all your reporting can now be inline - live.Your power users can be given Interactive Reports with a number of runtime manipulation options.
Oracle JET charts can respond to clicks, allowing drill down functionality, in whatever way you want.
Or you could go down the yellow brick road and choose a tool to dynamically generate PDF documents, Excel spreadsheets, Word files etc.
Visual Attributes
Template Options seem to be a fair comparison here, where common group of settings can be tailored to each instance of a component.Windows
Application workflow differs between Forms and APEX due to the nature of their environments.In APEX most interactions happen within the browser window, within an inline modal (just a special looking page region), within a page modal. From APEX 5.x this became native and easy, allowing modals to have validations and branches, just like standard pages.
Menus
Forms had specific menu files, controlled by database roles, and there had to be no active users to be able to update the .mmx file.The menu in APEX can either be across the top, or down the left side. These menus can be statically defined, or dynamically driven, even by the meta-data that is apex_application_pages view. (my link)
Static navigation entries could be controlled by authorisation schemes, or custom conditions.
Dynamic menus can have security tables integrated within the SQL.
There are a few list templates that follow the same data structure, just rendered in different ways.
There is a smaller Navigation Bar at the top right, typically starting with the login/logout buttons.
Canvas
Forms is WYSIWYG, I'm sorry for your loss. An APEX page needs to be rendered in a variety of devices sizes, so items go where the responsive templates tell them to go. You can impact this using the grid layout, but it can take a little while to get the hang of it. Showing the columns helps, particularly with item layout. |
| Show Layout Columns |
Properties
The Page Designer introduced in APEX 5.0 is rather reminiscent of Oracle Forms, particularly with regard to the ability to edit multiple components at once, only intersecting attributes, and obscuring heterogenous values.As with Forms, finding the right property can be tricky, or even being aware of its existence.
I highly recommend you take note of the inline help associated with each attribute. I'm sure this content improves with every version, even without inline feedback (hint hint).
 |
| Inline Attribute Help |
Let me know if you think I've forgotten something vital here, or misaligned features.
Here are some other links on the topic of Forms transition to APEX:
When Forms to APEX Projects get thorny - Rodrigo also responding to the AskTom session
Oracle Forms Migration - Some recent thoughts (that need some revision)
APEX 5 Page Designer walkthrough - my prezi session looking specifically at the Page Designer IDE.
AskTom Checklist
Office Hours Q&A
APEX for Forms Developers - Kscope presentation
No comments:
Post a Comment