Oracle Forms New Feature Ideas

RajeshAlex

SUGGESTION DETAILS

Allow special characters and line breaks for the  Push button.   

WHAT VALUE WOULD THIS ADD TO APPLICATIONS OR THE PRODUCT

Currently  forms builder does not support a multi line label for a pushbutton. Hence this can be set only in run time by using CHR(10)

Also it does not allow special unicode characters like graphic UP /DOWN which could be used as a symbol for SORT.

Recently I was implementing a sort feature for a multi record block similar to what APEX has.  I could not use the below characters

• ▲ - U+25B2 BLACK UP-POINTING TRIANGLE
• ▼ - U+25BC BLACK DOWN-POINTING TRIANGLE

EXAMPLE MOCKUP (IF POSSIBLE)

F.Matz

SUGGESTION DETAILS

One of the most important components is the Oracle Forms LOV.

Therefore, I would first like to propose the following change:

Data:

     - search-place:       {first-item | all-items}

     - search-algorithm: {auto-complete | auto-suggest}

      

Binding:

     - Item    (first LOV row)

     - Block  (result set of the LOV)

Layout:

     - simple table grid

     - search item

     - canvas property

     - button properties (e.g. `accept | cancel ..`)

Style:

     - Flat UI

     - color properties (schema)

     - row banding (Zebra stripes)

WHAT VALUE WOULD THIS ADD TO APPLICATIONS OR THE PRODUCT

Oracle Forms is a data-centric application system and so features for data selection and filtering are essential.

The proposed solution allows the user to quickly filter data according to modern best practice concepts.

It is also possible to use the LOV as a `read-only table grid` incl. data searchings.

EXAMPLE MOCKUP (IF POSSIBLE)

   e.g.: `all-items & auto-suggest`

             

               Search:  am              

               John               Silver                     Miami                   USA

               William           Richards                Birmingham          UK          

Cheers,

Friedhold

Christian Erlinger

Andreas Weiden wrote:The IDE is HORRIBLE if you have ever used a modern IDE. 

Couldn't agree more.

One maybe minor change of a feature which always baffeled me and caused us havoc:

SUGGESTION DETAILS

Remove the "feature" in the Forms API (which will affect the builder / the compiler / the JDAPI) that it removes attached libraries which cannot be found anymore in the forms path upon saving a file. Or at least ask before you get rid of them like eclipse does when you reference java classes in the import section which aren't in the classpath anymore like "there are libraries attached wich cannot be found in the forms path anymore. would you like to remove them before saving?" Y/N.

WHAT VALUE WOULD THIS ADD TO APPLICATIONS OR THE PRODUCT

Honestly I don't know what purpose that feature serves in the first place. If I dump a library I most certainly will remove the attachment from forms anyway. I am however certain that I am not the only one who started forms builder with an invalid FORMS_PATH, opened a form, accidentally saved it and had to reattach every single library by hand from scratch accompanied by an unusual amount of swear words.

Andreas Weiden wrote:Productivity. Feeling, that you work in the 21. century.

That made me laugh very hard until I started crying and crawled under my desk.

cheers

ben_g

@Andreas Weiden @Christian Erlinger I feel your pain

I have many suggestions and for my first one I'd like to expand on what Christian just wrote "I am not the only one who started forms builder with an invalid FORMS_PATH, opened a form..."

Background

My tiny team looks after 15 Forms and Reports applications, many 20+ years old. Over 800 forms and 350 reports in total.

We have 36 main code branches:

1 for each app

2 for Forms Java Beans that are full blown Java apps implementing JFreeChart and using JDBC

1 for a .NET developer workflow app that assists with branching, merging and preparing database and client patches

2 for .NET utilities invoked from Forms to perform client functions not provided by Webutil or to bypass the middle tier for database operations that are too slow that way, such as moving BLOBs

1 website for our users of Forms apps

The balance are mainly for libraries providing common database objects or Form libraries used in all our apps, one example being our application security layer involving base menus, forms, PLLs and database objects.

My point related to Christian's comment is: configuring Form Builder so it follows which branch I'm working in is a very tedious process and it could be easier to integrate it with WLS_FORMS

My Current Workflow

1. Perform a hack in the Windows Registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU for frmbld.exe to set its "most recently used folder" to the path for client modules in my branch. This is so File > Open automatically starts in that folder saving me from manually navigating through many folder levels to find the form I want to work on in the branch and version I need

2. Edit cauprefs.ora and set Forms.compiler_module_path = C:\path\to\bin\folder\matching\WLS_FORMS\env\for\this\app. This is so WebLogic and Form Builder are using the same FORMS_PATH folder for compiled modules

3. Edit cauprefs.ora and set Forms.html = "http://127.0.0.1:9001/forms/frmservlet?config=<formsweb_named_config_section_for_my_app>". This is so the correct formsweb.cfg config will be started which references the app.env file pointing to the FORMS_PATH that WLS_FORMS needs to run from

4. Modify Registry key HKCU\SOFTWARE\ORACLE\KEY_OracleHome1\FORMS_MODULE_PATH to match to the path for client modules in my branch, otherwise no attached libraries or menus as per Christian

5. Start Node Manager, Admin Server and WLS_FORMS

Only then can I launch frmbld.exe and start doing my job

Suggestions 1 and 2

I believe adding several new command line parameters would be too unwieldy. I'd prefer one new command line parameter such as: frmbld_config=<path_to_my_config_file>

The parameter would instruct frmbld to read its configuration from a file at startup. For example:

module=<path_to_my_branch>\application_main_menu.fmb

userid=app_schema/[email protected]

login_script=<path_to_my_login.sql>

MRU_folder=<path_to_my_branch>

Forms.compiler_module_path = C:\path\to\WLS_FORMS\bin\folder\matching\env\for\this\app

Forms.html = "http://127.0.0.1:9001/forms/frmservlet?config=<formsweb_named_config_section_for_my_app>

FORMS_MODULE_PATH=<path_to_my_branch>

Most of those should be obvious but I'd like to describe one that covers the second suggestion: login_script=<path_to_my_login.sql>

This is an SQL script to be executed after connecting or reconnecting to the DB, just like SQL*Plus and SQL Developer already have.

The requirement this fulfils is when I need to debug in Form Builder using an application user instead of the main application schema you'd typically use. You need to do this when developing or troubleshooting problems with your menu form, menus or application security that all have to work for the application to startup successfully.

My form builder login.sql would contain commands such as:

ALTER SESSION SET CURRENT_SCHEMA=<app_schema>;    (for when I haven't polluted my database with a million public synonyms )

SET ROLE <database_privilege_role> IDENTIFIED BY <role_password>;

And this would probably be useful for similar things, for example connecting to a container DB and then: ALTER SESSION SET CONTAINER = <PDB>;

Benefits

Easier configuration of Form Builder that aligns it with WLS_FORMS

Tighter integration between Form Builder and WLS_FORMS improves developer workflow

Permit debugging of application startup as an application user and debugging other forms as an application user

Michael Ferrante-Oracle

@Christian Erlinger @ben_g

You almost had me with this on.  The idea that the PLL attachment is removed if it can't be found when the module is opened.  But then it occurred to me, why would you want to keep the reference?  Without the file you won't be able to compile any PL/SQL that calls PUs within that library and you won't be able to generate the form into an X.  So what's the point of just having it show up in the Object Nav??  Why not just fix the problem?  Close the module without saving (leave the Builder open); add the missing path to FORMS_PATH in the Registry; reopen the module.  Done...

Ben, regarding your need/desire to have unique environment settings for various projects, you are proposing that the Builder accept an arg that reads a configuration file of choice.  Although not exactly the same as your suggestion, you can already do this.  Rather than having config files, just make your config file idea a batch file.  This is how it is done on Unix.  Then you can have a batch/script for each project.  In each file you can set exactly the same entries you see in the Registry.  In fact, this is how I have multiple versions on one machine.  I remove all the system settings (e.g. PATH, FORMS_PATH, etc) that reference Forms and enter what I want in individual batch files.  This would give you exactly the behavior you described.

Finally, the Builder has absolutely not relationship with ANY of the servers in WLS.  So you can start those servers at any time.  And "FORMS_MODULE_PATH"?  Why are you modifying this on a developer machine?  In most cases, there is no reason to make changes to this other than possibly remove the value(s) completely.  By setting this value to null/blank you can enter your module (X) path in the URL.  You should be editing FORMS_PATH in most cases.

And finally, are you aware that you can set the X file output directory in the Builder?  You don't need to set it in config file unless you want different values for different projects.  That said, the output path is currently not available as an environment variable so it can't be set in a batch startup script.  I'll look into this.

Christian Erlinger

Michael Ferrante-Oracle wrote:Christian Erlinger ben_gWithout the file you won't be able to compile any PL/SQL that calls PUs within that library and you won't be able to generate the form into an X.

You are missing the point. I don't care about compile errors at that time. Suppose I opened the form with an invalid forms path without noticing (or ignoring) the invalid library attachments and start hacking. Now I either have to revert all my changes (by not saving the form) or destroy the module (by hitting save). I could save, do a svn diff to see what libraries were attached before and reattach them, but hey, the beauty of oracle forms source binary files also prevents that.

The point is that Forms Builder (a IDE) itself destroys a source file just because the environment which is controlled by something totally different might be invalid.

Another possibility: I need to patch a bugfix from one branch to another. In every single other tool where source code is not stored in binary files I'd get the file(s) in question from version control, patch my changes and commit the changes. Enter oracle forms: there is literally no way I can do that - at least I'd have to get all the referenced libraries. Oh, and the subclassed forms referenced. And the object libraries. And what ever else I just forgot. So in the end I'd have to check out an entire branch just for adding one single if statement to one single program unit in one single form. Some of our libraries are based on generated code, so I have to generate them as well if I don't want to loose that attachment in the forms file in question.

I don't care if all the libraries are there or not at development time. Compile errors are OK at that time. If the FORMS_PATH is invalid at development time Forms Builder - on purpose - makes sure that the forms file in question will not be compiled anymore except I fix the path and revert all the work Forms Builder has done.

If at build time in an environment with a 100% correct FORMS_PATH the library still isn't there I get compile errors and the build fails anyway which also is the correct behaviour. The solution is simple: don't touch the source files unless I tell you to do so. As said - an eclipse like behaviour - the choice "there are library files which are not found in the FORMS_PATH would you like to remove them y/n" would be totally OK with me.

cheers

Marwim

Whenever you want to help a coworker with a simple fix for one of his modules (maybe because you have changed a package he uses) you have to find every pll etc. before you can do so.

Usually we don't even compile a module locally but copy them into a server directory where a job looks every minute for new files and compiles them.

Jeremx

Hello,

features :

- svg icon / image and no longer have a jar for icons (certificate management for images ...)

--> storage in the pll / fmb or server ...

- simplified installation of cluster forms

- forms builder without weblogic -> compilation / runtime via a remote server

Walid KHARRAT

There are a lot of posts related to the development workflow, so I add my case:

In the case of my clients, there are different observations about developing with oracle 12c forms:

- the target operating system is linux

-the current form cannot be executed directly, usually there is a front login screen and different menu levels (a whole context of forms and pl to initialize)

- there is already an fsal or forms browser runtime that we don't want to restart all of this, so as not to lose the context.

Currently, the forms generator generates an fmx file (without saving fmb), launches the forms servlet and "posts" some parameters in the servlet (the fmx path, the user ID ...)

a better alternative is to add one or more buttons to perform execution with a custom script.

in this button, the forms will do these steps:

1- save the fmb in a temporary folder.

2- start the cmd program with arguments like the temporary fmb.

the cmd program (java program, I will write it)

1- Download the temporary fmb file into a servlet of the development application server.

2-compile the form

3- inform if the compilation succeeds or fails (if the compilation fails, display the .err content)

4- if the compilation is successful, copy the fmx in the directory linked to the developer.

all this can be done in the same servlet (upload, compilation, fmx copy or return from .err ...)

The developer can now access the fsal application (currently used with its env and forms_path), exit and enter the form from the menu for testing.

with that, i don't need to install weblogic for every developer.

I don't need to launch the forms directly because the form is usually accessible from the login screen and from different menu levels

Walid KHARRAT

sample windows shell scripts or exe to install portable jdk, fsal, create shortcut in the desktop...

FSAL will change the install of client pc, a simple url in ie is no longer sufficient, so you can help with windows scripts or/and utilities to do the client installation.

For example an equivalent of wget in windows. If i put frmsal, portable jdk and .bat file available for download in http server. a script to download these components in windows folder, create shortcut to the desktop ...