I'm sitting at LA airport on my way to the ODTUG conference, having been up for just on 24 hours with 20 hours flying time behind me. Unfortunately my UA flight to Denver has been canceled, and now I'm waiting 7 hours for the next available flight direct to New Orleans. Being one of those people who doesn't really sleep on planes, and certainly not in airports, I'm calculating I'll be up for just around 38 hours before I finally hit a bed.
(+1 day edit note: oh well, it was only 34 hours in the end, not too bad really, can't complain ;)
Sheesh, one day a flight through the US will go without a hiccup.
Anyway, this leaves me more than a couple of minutes to let you know Penny Cookson and I are happy to announce our next Oracle Tech Network article, Return to Formsville has been published. I've listed a blurb of the article below which hopefully will catch your interest.
Some readers might be surprised that we've published an article on Oracle Forms given my blog interests in JDeveloper. In fact my boss Penny Cookson and I come from a strong Oracle "core-tech" background of Designer 100% generation, meaning a substantial background in Oracle Forms programming, and even a smattering of Oracle Headstart in my case. Thus why my last 2 OTN articles have been based around legacy artefacts from Oracle Designer and Forms; I'm interested in boot-strapping that old code base into something we can still use in the future.
For those interested, the other previous OTN article was Integrating the Oracle Designer Legacy Table API with Oracle JDeveloper 11g ADF Business Components.
I can't say I have any interest on moving back to Oracle Forms, but this attitude doesn't pay the bills, and from time to time myself and Penny and other Sage employees still maintain and extend the odd Oracle Forms system here-and-there. Sage Computing still in fact offers Oracle Forms training in Australia.
A final note of thanks to Justin Kestelyn and the OTN team for assisting us in the publication of this new article.
Returns to Formsville
New programmers moving into Oracle sites running legacy Oracle Forms and Oracle Designer applications face many challenges. New programmers rely heavily on their senior counterparts to teach them how to structure their applications, as well as the benefits of such structures from hard-earned experience. There are certainly plenty of best practices around for Oracle Forms, and Oracle Designer gave its own particular stamp to Oracle Forms architecture. Yet at many sites, senior programmers have moved on, leaving their successors guessing why applications are structured as they are. With the pressure to fix mounting maintenance issues, the elegance of the original solutions can be jeopardized.
For those starting their Oracle Forms journey, this article attempts to explain the key architectural concepts that are common to many Oracle Forms– and Oracle Designer–based applications, including their benefits and how you can use them to your advantage. In particular, the article will focus on:
* A simple Oracle Forms trigger architecture
* A flexible Corporate-Application-Form Oracle Forms library architecture
* Extending the approach to forms generated from Oracle Designer
* Oracle Designer artifacts, including the table API, cg_ref_codes, and journal tables.
5 comments:
Chris,
I'm a PM for Oracle Warehouse Builder, and I just went a little nuts trying to figure out how to install JPublisher on the 11g database... posted an update to your thread on the OTN forums, if you are interested.
http://forums.oracle.com/forums/thread.jspa?messageID=2589780�
See the end of the thread for the explanation of how to do this install.
Also, I will be at ODTUG this week, and perhaps we will run across each other at some point.
-Antonio Romero
Senior PM, Oracle Warehouse Builder
Thanks for the follow-up Antonio. In fact I needed to know this for an upcoming presentation, so you've saved me a big headache! Hopefully I'll catch you at ODTUG to give you thanks in person.
Cheers,
CM.
Not sure about this "massive if-then-else" approach achieving anything but code bloat, quite frankly.
One of the characteristics of Forms coding is precisely that it avoids the need for these constructs with item-level triggered logic by design. IOW: event-level code response.
This of course has the drawback of code fragmentation as you very well note, with potential negative impact for code maintenance. Hence the need for frameworks such as these to circumvent that specific problem.
Your approach however involves an add-on of a massive "selector" to determine which event was triggered, for something that has already been determined by the nature of the product and how it works. It achieves next to nothing in terms of ease of maintenance, IMHO.
My approach to coding PL/SQL in Forms is slightly different: code a forms level package with procedures for each of the major functionality - be it event or application functionality, that is left wide open - followed by calls to procedures inside that package by each of the events where I want to have some code behind.
That way code is isolated into high level and still available to all item-level actions, just like in your approach.
In very complex forms I go for more than one form level package, with each handling specific aspects of Forms functionality across a number of items.
Code is still maintained essentially in one spot and enabling/disabling sections of functionality is provided by testing a boolean package constant at the start of each procedure in the package.
If it is enabled the code executes, otherwise skip to "no-op at end". Enabling or disabling is done by changing the package constant at the header, with a common naming convention for these variables being "procedure_name_toggle".
Really not much different from your approach, although no need for that massive statement and the complexity of maintaining it. While still providing a means for easy code toggle without complex logic to sort out, as well as code centralizaion.
Still: just a different approach that has served me well over the years.
Interesting approach Noons and I appreciate you putting pen to paper. This stuff needs to be captured. Sounds like a good paper for a conference to me.
I disagree on your point about the if-then-else, it's never been large enough to be an issue for me (mainly because it's broken up by block-package). The trigger splatter problem it solves is a serious problem for junior programmers because they hack and slash and don't understand where they're actually adding code (as you agree) or when the triggers fire, I've seen it first hand several times more recently; "they're just not getting it, Forms is foreign". And for the record this is the approach Headstart took. But we can agree to disagree can't we? Or at least document the different approaches.
As for the importance of communicating either of our approaches, an increasingly important issue as more and more junior programmers replace the retired senior counterparts.
Nice to see there are still other old-Forms-hands about.
Cheers,
CM.
Oracle's reorg of their URLs has shifted the article to:
http://www.oracle.com/technetwork/articles/muir-forms-096750.html
CM.
Post a Comment