Customize interface without touching the source code

Question

My VP of of marketing is at it again. I have pasted in the exact email that he sent me. If anyone has ideas or suggestions or knows if Forms 9i has this built-in capability, please let me know.
Thanks.
Can you post this on metalink and see if someone at Oracle (or elsewhere) has an answer for us? Somehow, other LIMS developers are distributing LIMS products that allow their users to customize the interface without touching the source code -- no impact on their ability to take new releases. How do they do that?
Here's my question:
Anyone familiar with the Tools / Forms / Design this Form feature in MS Outlook? This allows a mere mortal to actually create and publish a custom Outlook form (could be a Contact, Task, Note, Journal, etc. form) across the organization. Is there such a capability built into Oracle9i Forms? In other words, can a developer easily build and distribute an Oracle software app such that the end-user can use an administrative tool to modify the interface/forms, add fields, change field names, move things around on the form, change colors, etc. -- without needing the Oracle Developer tool used by the original software developer, along with source code?
Here's my original email from a few months ago:
Our VP of marketing has been on my case about the ability to allow customers to "map" a form label (prompt) to a "custom" label of their choosing. The only way I know to do this is to create a "mapping" table and each time a form opens have code in the Post-Query trigger that changes the prompt of each column to the label that is in the "mapper" table. My fear here is Performance. Also, if the user closes that form and comes back to it - that logic has to be executed again - once again Performance. We have thought about the global variable idea, but we have over 100 tables with approx. 20 columns each. That's alot of globals to carry around. What's the overhead of carring around let's say 150 global variables?
My questions to all of you are:
1) Is anyone else doing this exact thing?
2) If so, what is the performance hit?
3) Is there a way to "remember" after the first time it paints - until the application is closed (not just that form) - other than global variables?
4) Is there a solution already in place within Forms for this?
5) Is there newer technology that has overcome this problem?
My VP doesn't like the mapping idea. He wants to know isn't there a better way instead of mapping all the fields. Isn't there some simple utility provided by Oracle that allows the user to simply change the form labels (no, he's not talking about Oracle Developer). He is a real Outlook nut. So he's always comparing everything to how Outlook works. This is how it works in Outlook -- you click on Design Form, modify it, then install it on the machine. Surely Oracle must have something like this. He thinks we're asking the wrong question or not asking it in the right way. I'm not sure how else to ask it. Our users want to see "Date of Birth" spelled out instead of "DOB" as the label for a column on a form. Is there a way for them to take the fmx and change that label? Is there a better way other than storing this in a table and querying it up each time the form opens? Yes, I could use a global so I don't have to query it from the database every time, but I still have to evaluate every time the form is opened during that session to see which label I need to use and then set the prompt accordingly. Our VP doesn't like this, he wants this to be a one time change.
Thanks so much for you help,
Tina

Answer 1

Hmmm.... either your VP of marketing or the users have too much time on their hands. ;-)
I would go with a lookup table. If your database is responsive and you index the table by form name, you can retrieve a number of rows and setup the screen quickly enough that nobody would notice any time lag.
If there aren't too many titles stored in the form, you could use a PLL library procedure and stuff all of them into a few globals -- just stack them into a single string separated by an odd character, like maybe chr(3). Then when the form is called again, it could first check to see if the globals exist, and parse the titles from there.
But be careful about changing field titles. If they change DOB to Date of Birth, the length changes, and so you need to determine where the extra length goes. The title field must be wide enough and the text justification should be set properly.