We have a huge application based on hundreds of Oracle Forms and Reports files. After having a look to Formspider it seems that I need, for each Oracle Form, to create several panels and actions. This means too many objects, maybe hard to be maintained without some "tricks" or best practices. This is one of my manager's concern.
The other concern is related to application modules. When the customer wants to buy a new module, which are required by his business, we had only to provide the new set of forms and reports files and run some logic into the database and the new module was provided. How can we build such modules in Formspider? One way could be to build each module into its own application and provide some links in the menu to switch from one to the other, with the problem of having same login session available in all of them. But with one drawback, if I want to have two panels opened in same window, one from one application and the other one from other application then I feel its impossible. Or is feasible? The other option would be to build everything into a single application and somehow be able to split the big application into modules. Feels more complicated when there are thousands of objects to split.
Thus I am coming to you to get some best practice hints for above concerns we have. We have seen that some of your customers already built such big applications.
In order to decrease the number of actions (not having for each form button a distinct action) we think we could define some standard actions, and depending from where we make the call to do different things (like in your wizard learning application where the next action is sending you from one panel to the other). Is it the only way (best way) to do it? Having parameters to send dynamically to the action is not possible (as bind variables or such). We would like to define some standard actions and then just reuse them without having to implement a huge list of case statements or a table to store all the input - output actions to perform.
Maybe there are a lot of other questions to make (we are still at the beginning with Formspider understanding) but I suppose having answers for these would be enough for the manager to start a project to asses the Formspider solution and create a pilot application for the top management.
Thank you very much Radu Florescu
asked 20 Oct '15, 04:23
Just to address some of your concerns:
Indeed for each form you have to create a set of panels (our biggest 'forms' have few dzens of panels). In total we have several thousands of panels in our application, but my experience is that working with just a few or with thousands of panels does not make a big difference. The list of panels quickly grows too large to use scrolling in the Formspider IDE to find the panel you want to work on anyway, so it all comes down on a good set of naming conventions for all FS Objects you create, wether you create 10 or 1000, that does not matter.
We also came from an Oracle Forms (and Designer) background so we were very used to give each 'screen' or 'form' an own code, starting with a 3 letter application prefix and then a form code. For example we use a form code like AUTGRP010 for our 'Groups' form. So, if we want ti work on this form, we just use the filter in the FS IDE to restict the list f FS objects, so you get something like this:
A nice list with clear panel names. Again, working like this with having thousands of panels is no issue at all in my experience. Having hundreds of Oracle Forms is also hard to manage without some proper naming conventions in place, isn't it?
When i started with Formspider coming from Oracle Forms there were two thngs i found missing:
You are right, this type of 'modularity' is not possible with Formspider (yet). I have raised the topic with FS before and i think it is somewhere on the roadmap, but until now, you cannot directly use parts of one application directly into another.
There are several ways to approach a 'modular' type of application, depending on your needs. The easiest would be to deploy the complete application, and make only parts of it available via the menu depending on what the customer paid for. Just 'unlock' parts after the customer paid for it. Exporting only a part of a FS application i believe in version 1.9 is no longer possible (you would have to manually modify the exported full XML), and like you said it would be very tedious to maintain such partial exports)
That approach is certainly possible and i know some have taken that approach. It is a matter of preference how far you take that approach though.
We have created generic standard procedures for regular CRUD / Master details related actions, based on a self create application 'repository' where we store information that is needed for this generic code to work.
Extra FS object do not cost extra money or eat bread, so i personally do not mind and find it often easier to be able to pinpoint where an actions leads to directly from within the FS IDE. But again, all options are open and the only way to find out what you liek most is to try it.
The nice thing of FS is that this is not needed in most cases, though it is possible to use for example FS API calls inside the action procedure definition (but i would not recommend doing that). You are able to get all UI info from within the DB through FS API's. You can know what what button was pressed and so on through the FS event that triggered the action.
This post is getting too long ;-)
answered 20 Oct '15, 16:27
Right you are. There is no automatic tool to convert fmb into Formspider XML. But Formspider has the similar concepts with Oracle Forms, so it's easy enough to move basic logic from Forms Design into Formspider Design. The last version of Formspider supports stateful database connections, Oracle RowID, complex primary keys: it significantly simplifies migration.
You can develop a new module as a part of the big application, and after that do export-and-deploy objects just related to this module. Or you can develop one application per module and pass session condition whan call it.
It's possible. You need some tricks to use Formspider non-modal dialogs as windows (I hope the Formspider Team will implement correct window switching in future releases).
Yes, FS API can operate with panel and object names, so you can create a standard library to reuse it in different modules (like a toolbar or an action for 'current-record' to colorize required fields in forms).
Something like standard messages to call from anywhere, right? Formspider API operates with string-names of interface components, so it is flexible enough.
Best regards, Andrew Pouckatch
We have also come from oracle forms. We found formspdier easier to learn and work with.
Instead of answering each of your questions separately I will tell you what was our migration plan.
A little background. Our development in Oracle Forms was repository based. It is a four table structure for keeping details of each of the following. 1. Forms 2. Blocks in form. 3. Items in each of the block. 4. Language for each of the items for storing label, tooltip etc. language wise. We are using the same repository for formspider as well. This enables us to develop simultaneously in both Oracle Forms and formpider. Of course we had to add additional columns for formspider specifically. And again two additional tables were newly created for formspider. One for keeping all the panel names for each of the forms and another for keeping the table relationship.
We have a standard simple panel structure used for all formspider forms. The panel table specifies which form panel will go to which simple panel and the same is dynamically added at runtime.
The development and implementation for new form in formspider is. 1. Create new panels (for this we have a script in Oracle Forms. Run this script and copy the generated XML into formspider as a new panel. We have a set a standard for our XML script). 2. Add the panel names to panel table and specify as to which simple panel is used for each of the newly created panel. 3. Setup the table relationship. That's it. Form is ready for running. Our oracle forms never kept any PLSQL for backend processing. It always contained only code for opening and running the form. As such migration to formspider became even more simple. For new formpider form with say, ten panels, will take around 20/30 minutes for migration.
About action objects. We have a total of 73 actions in formspider. Some of them were added while learning formspider which will be removed in the optimization phase. For eg. in all our system we have a single formspider action object for buttonPressed, doubleClick, rightClick etc. And for each of them we have a PLSQL procedure being called. See, the more objects you have in the system the more work and more cost.
About application module. As you suggested, the best solution is to put everything into a single application. Install this full application as a new implementation and hide the irrelevant menus. Eg. A construction company will get only construction related menu while manufacturing company will get a different set of menu. If the company does both, enable both types of menus. Later if the company ask for Trading module just enable related menus. That's it. Module addition/deletion has nothing to do with formspider. It is a general software implementation issue.
answered 21 Oct '15, 05:36
Thank you very much for these detailed explanations and hints.
I am not very sure how to do all the things yet, how to reuse all the actions, as George suggested, or just create few more actions where reusing seems to be more tedious than just having a new one (as Michiel suggested). Just yet. But as soon as all of you are very enthusiastic and very confident that this is the right tool to go on, I am pretty sure that with this good start, with all your suggestions for which I have a big Thank You, I will be able to find the right way to implement everything. Not scared anymore :).
I will take one step at a time, trying both options you suggested for application modularity:
It was a startup idea, a nice to have feature, but really not mandatory. The client was used to have only one form open at a time. In FS there will be few in same window, all from same module. If he needs more, from another module, just open a new browser tab with them.
Thank you Yalim for reminding about the webinar, I just subscribed to it. Most probably few questions I haven't "seen" yet will be answered.
A big thank you again for all of you and happy journey with FS :)
Regards Radu Florescu
answered 23 Oct '15, 15:15