Hi,

I have developed a sample master-detail-detail application in order to understand Formspider and study the countless API-functions and procedures.

Along the way i discovered many potential problems or items that could have been forgotton easily. For example:

  • It is easy to control the synchronisation between masters and details, but what to do when there are changes pending? You can not just query details - first changes have to be committed.
  • Create a new master but prevent the question about saving changes (as soon as you create a record, the datasource is dirty, however, you only want to ask the user to commit when he is updating records). This a complex chicken-egg challenge.
  • Check referential integrity when deleting masters.
  • Use one set of icons to create and delete records in all panels (instead of icons for each panel)
  • Trace users updating/inserting records

It does remind me of the early Oracle Forms years when the was not yet a Designer Generator and you also had to think about everything :)

My conclusion: the learn curve for Formspider is exceptionally good, but it is certainly not a simple product to work with. I am almost sure that i have forgotton something in my sample application, but what?!

Is there is a checklist available to make sure that i have not forgotten something?

Offcourse there are sample applications on the formspider website but i am afraid that my sample application has already gone beyond their functionality :)

Kind regards, Jan Willem Vermeer

asked 12 Sep '15, 09:30

Jan%20Willem%20Vermeer's gravatar image

Jan Willem V...
1231331
accept rate: 0%


12next »

Hi Jan,

First of all, congratulations on your speedy progress. I am happy to hear that you think the learning curve is exceptionally good. This is one of the main points we are trying to achieve. The fact that you are worrying about Master Detail Detail applications after such a short time with a development tool makes all of us here very happy. :-)

Regarding your question about a checklist... I don't know if there is a special check list for Formspider. I think there is a generic check list for building master-detail-detail applications regardless of the technology you use. I don't have it written anywhere (and come to think of it, I should do this) but the bullet points you wrote seem like a good start and like I said this does not change depending on the tech stack you use. It is always the same check list.

I understand that you miss the good old Oracle Designer and the code it generates to enforce most of the stuff needed to build MD, MDD apps. Formspider is not there yet, but it doesn't mean that it will not get there. We are finishing the building blocks first. Once we have the solid infrastructure, we'll build the tools that will make your life easier. Give it time please. :-)

Kind Regards,
Yalim

link

answered 16 Sep '15, 08:40

Yalim%20Gerger's gravatar image

Yalim Gerger ♦♦
1.8k5
accept rate: 15%

edited 16 Sep '15, 08:41

Hallo Jan-Willem,

The way i approached this was to build an 'application repository' with a definition of the structure of your application. I start my build of a form with creating the definition of the form (the Formspider structure) in my application repository tables (i.e. enter form code, form name etc), then the form master and detail (and detail-detail) datasources and their relations (foreign key relations).

Based on this repository structure i can generate a generic form database package that has all the checks needed for the master-detail(-detail..) relations and the dirty checks etc. This way a developer does not need to think about this kind of basic scaffolding code, it just works when the structure definition inside the repository is correct. Adding an extra detail datasource is as simple as adding an extra details datasource to my repos definition and all checks work.

Het an example of a form definition in my repository:

alt text

alt text Generating the form package, i create a generic form specific package with default procedures, like:

create or replace package autgrp010_pck
is
    procedure init; 
    procedure ins;
    procedure upd;
    procedure del;
    procedure pre_commit;
    procedure post_commit;
    procedure post_tab;
    procedure master_row_changed;
    procedure master_row_changed_nocheck;
    procedure master_dg_row_changed;
end autgrp010_pck;

For this to work of course you need to know how you want to structure your application, but in my experience creating your own application repository will give you the possibility to make a lot of code generic and thus reusable. It is kind of like making your own Designer/Generator tool on top of Formspider..

Just wanted to share my 2c on the subject, because i think it is one of the important things to consider when starting to build a larger Formspider application (don't repeat yourself.. build generic code and (re)generate as much as possible..this will improve quality in my opinion)

Best regards, Michiel A.

link

answered 17 Sep '15, 05:10

Michiel%20A's gravatar image

Michiel A
5161546
accept rate: 13%

edited 17 Sep '15, 05:11

Hi Michiel,

This is exactly what i meant !!

I am now developing my first "real" application with approx 40 DML forms (many of which are MD or MDD and almost all have query panels) and 30 reports and have to write similar plsql code over and over again. Sometimes there are little differences (for example - on some MD forms new masters can be created, but others only query the masters) but most of the time they are the same. And offcourse with my yet limited experience, chance of making mistakes or forgetting something is relatively large.

In your images above, i see a tree menu. My application will also have a menu tree and to be honest, i am searching for perfect icons/symbols for hours. And you have them...

Same story for the navigation and action buttons. I have now taken Yalim's icons, but yours seem to be different (and better :). Do you have standard plsql for enabling/disabling these buttons depending on the grid the user is in and the settings for the grid in your application.

Does your application also generate the Formspider datasource definitions, containers and actions? If so, you own the first Formspider Generator :)

So, the conclusion is clear... When you started to work with Formspider, you walked into the exact same problems/questions i have now.

Kind regards, Jan Willem Vermeer

link

answered 17 Sep '15, 06:08

Jan%20Willem%20Vermeer's gravatar image

Jan Willem V...
1231331
accept rate: 0%

Hi Jan Willem,

Indeed, when i started to develop with Foprmspider (back in late 2011 on beta6 :) i indeed had the same issues/questions you have. Also coming form a Designer background the first application i build was this repository application. With that i can plug in my 'real' applications in the main application menu and start using the rpository app to build my real apps.

(very) short overview of how we create new forms in FS in my applications:

  1. Create views with instead of triggers for the form datasources (i generate these based on tables and i always use views!)
  2. Create the Formspider datasources (no generator for that)
  3. Define the new form in the (repository) application (form code/name, used datasources for master and detail etc)
  4. Define the menu where the form must appear in the application menu (also in the repository)
  5. Generate the standard form db package
  6. Generate the standard Formspider panel structure (i have a generator built in Formspider for that, see image below). This will create panel xml definition in Formspider, ready to use in the Formspider IDE
  7. Manually complete the build of the form using the generated panels (or create new ones of course)
  8. Done ;-)

Form panel generator: alt text

Customized grid and form panel XML generator alt text

And some other generators we built to support the developers: alt text

As for the icons, i used a set of open source icons named 'Iconic' and customized some of them when needed. The tree icons require some CSS and modified images.

I hope i inspired you to build some great application with this great tool :-)

Best regards, Michiel

link

answered 17 Sep '15, 06:52

Michiel%20A's gravatar image

Michiel A
5161546
accept rate: 13%

edited 17 Sep '15, 06:55

Hi Michiel,

Congratulations: you have indeed created "Formspider Designer" !

It provides standardisation, prevents errors, saves a lot of time, well, i guess every Formspider developer would benefit from it. Did you ever talk with Yalim about the possibility to add this program to the Formspider set?

Now my problem.... my application has to be ready in the end of October. That's no choice, but a deadline because countless users have severe problems with the Java plugin for Oracle Forms. So, i will never have the time to build my own "Formspider Designer". Also, because i am a one-person-conpany, there is not enough time to study useiconic.com although it would be perfect for my case. But you have figured it all out ! So, theoretically it would make not much sense to re-invent something you have been working now for years. I have sent you a linkedin invite to talk about this.

Kind regards, Jan Willem

link

answered 17 Sep '15, 08:53

Jan%20Willem%20Vermeer's gravatar image

Jan Willem V...
1231331
accept rate: 0%

Thank you Jan Willem, I will accept the invite.

I agree with you that having such an 'Formspider designer' or 'Framework application' as i call it, will greatly benefit a lot of people that want to build with Formspider, but do not have the time/knowledge or money to invest in such a framework application.

Imagine what could be possible is Formspider will have the possibility to use an application like mine as a 'plugin' application. Then people would only need to plug in the framework application, and start building their applications without having to think about all the basic stuff (like multi-tenancy / querying / saving and restoring table layouts / master-detail check synchronization and dirty checks etc etc / The Formspider community can then build plugins and build an entire ecosystem of Formspider applications you can plug in ..

In my opinion that can mean a great boost in adoption of the Formspider tool..

So @Yalim: here is another requestor for the plugin / modular features in Formspider :-))

link

answered 17 Sep '15, 09:39

Michiel%20A's gravatar image

Michiel A
5161546
accept rate: 13%

Hi Michiel,

We are working on modularity, plugin features in Formspider. Should be ready sometime in 2016.

But I think your Designer/framework is still very very useful with or without plugin/reuseability features in Formspider. I'll email you now about what we can do about your work.

Kind Regards,
Yalim

(17 Sep '15, 09:50) Yalim Gerger ♦♦

Hi Michiel,

Your work is wonderful and demands great appreciation. Probably the formspider team should incorporate it to the benefit of all formspider users.

But I have been thinking in a different way. In my system I have made everything generic. For example, there is only one COMMIT/EXECUTE_QUERY command in all of my system. These are the two main commands through which we mostly interact with the database. No need to add any code for news forms being added.

And further, I have only one custom made LOV in all my system which is auto-reducing with the facility to search on multiple columns. Formspider LOV is not auto-reducing nor facilitate to search on multiple columns.

When I need to create a new form I simply generate an XML script and setup the relation if required. And my relations ship is almost always GUID_PK=:P_GUID_PK. Even before coming to formspider, I always had primary key GUID_PK for all my tables as if a God given fore-sight for easy use of formspider. The relationship back end script is again automated. No need to write new script.

Further, I do not have any special search screen. I have incorporated facility to search on any column in the currently running form just as in oracle forms. User presses key F7 and the form goes into search mode. User enters value (partial or full) into any column and presses F8 and the search is executed and the form is populated based on the values entered.

Once these features are perfected, my interaction with the formspider development tool will be reduced to creating the datasource and then copying and pasting the generated XML script to formspider.

I have almost ten Dialogue boxes, less than seventy Action objects and less than ten objects in Miscllaneous section. These will remain same even if I keep on developing any number of new forms. Of course, I will need to add XML script for all the new forms. And that's the only work I need to do in formspider apart from creating datasource. I want to avoid even that and I asked formspider team as to how to generate XML at run time. But they did not answer. I asked because I read your comment that formspider facilitate XML generation at run time.

In short, these features help me to concentrate more on business rules and not on the development tool. If the company have a large development team, only one may need to work with formspider while all others can concentrate on the back end database development. When a new form need to be created the developer does not have to worry about execute_query, commit, search, LOV or setting up relations.

I learned this way of developing from others during my development in Oracle Forms.

I put these here just for sharing of thoughts as we both think in terms of developing using generic code. May be there are others who have gone in a different direction to achieve the same result with less amount of work. I will appreciate if similar thoughts is shared here for the benefits of all.

Regards.

George.

link
This answer is marked "community wiki".

answered 20 Sep '15, 09:01

grajan777's gravatar image

grajan777
1011230
accept rate: 10%

Hi George,

It appears that you have "translated" the Oracle Forms functionality into Formspider. I have doubts about that and am wondering how you think about the following subjects.

1) One generic panel with buttons or one panel for each datasource grid/panel? With one generic panel i can imagine that there is less coding necessary. BUT, in my world the percentage of users with tablets and smartphones grows every day. One panel at the top only works on screens that display the whole form, so i think i can better make buttons for each datasource. Also, not all panels require/allow the same buttons, for example read-only grids do not need buttons to create/delete records. So you have to disable.hide them. It is very difficult to accomplish that because of the stateless concept of the panel.

2) Use of function keys (F7/F8 searching, F3/F4 duplicating values, F10 commit, F6/ShiftF6 create/delete records. Users on Macs, tablets and smartphones do not have function keys (or they do not know how to use them). What is easier for a user with such devices: entering fields in a search panel and just press a large button SEARCH or first put a panel is "enter query" mode?

Two of the most important reasons to stop working with Oracle Forms are: 1) Java does not work anymore in browsers Edge and Chrome and updates are very amateuristic with resets of parameters and 2) Mister Apple has convinced millions of people that user interfaces must be simple and work intuitive.

In my opinion we do not only need to rebuild the functionality we implemented with Oracle Forms, but we also have to build a new generation of user interfaces.

My users expect such modern "user experience". Formspider uses the most modern software available, but the applications look 30 years old! I am really proud of my first applications but users ask me two questions: 1) Why don't the panels rotate on my tablet? and 2) Do you really believe this is a modern user interface? And then they show me their ipads...

Offcourse, users will learn to use the applications easily if they look like Oracle Forms. But i am convinced that these kind of user interfaces are history soon. We need responsive forms that can be used on any device with a user friendliness everybody is used to with their smartphone. With Formspider that is not possible yet. Dimensions are in pixels and there is no responsive behaviour. However, the technology used would make it possible for the Formspider team to implement such innovations. But if you now stick to the old Oracle Forms concepts, it will be harder to use that. So, i try to do as much as possible to build panels that are more modern than Forms because otherwise users do not take me serious.

Kind regards, Jan Willem Vermeer

link

answered 20 Sep '15, 10:21

Jan%20Willem%20Vermeer's gravatar image

Jan Willem V...
1231331
accept rate: 0%

I forgot something... I wrote this because we are all doing an awful lot of work to accomplish that applications behave like Oracle Forms as much as possible. I think we should NOT do that. Do you ever press SAVE in an app? I think the concept of transactions and committing DML in multiple datasources is changing. We can better spend time in building new interfaces than trying to rebuild old ones.

(20 Sep '15, 11:03) Jan Willem V...

Committing DML in multiple datasource cannot change if you are using related datasources and change more than one datasource in the screen. It will destroy data integrity.

However, if you are using unrelated datasources in a single screen you are right, in my opinion.

(20 Sep '15, 11:51) grajan777

Hi Jan,

  1. I have single toolbar panel for all my forms throughout the system. For a form which does not need commit, the commit button can be hidden or disabled. Is it easier to have a single toolbar for all the forms or separate toolbar for each datasource? In the second case you have more objects to work with and makes it difficult and costlier to maintain. Some of my forms have above ten datasources. That means ten separate toolbars. This separate toolbars consume my screen real estate, reducing space for displaying the data.

But I never mentioned about the toolbar in my answer above.

In my case all the settings are stored in database tables for each screen separately. The columns to be displayed/hidden, column insert/update flag, column enable/disable, the labels, the width, color, tooltip text, help screen text etc. are all present in this table and can be changed at runtime.

  1. F7/F8/F10 etc are meant for users who want to migrate from oracle forms. There are related buttons available on the toolbar for these functions. Further, these can be remapped for new installation as per the user feedback by simply changing the mainframe in formspider.

Of course, you do not need to rebuild the functionality from Oracle Forms. But, what is the problem if a user is able to use the same screen for both data entry and search. Is it better to add a new search screen for every form you create or use a single procedure for all the screens? In the second case, both the developer and users are working with fewer objects which is easier for both. Further, maintenance become extremely difficult and costlier if you add more objects to your system. Also note that in a separate search screen not all the columns in the data entry screen is available mostly. Further, does a search facility has anything to do with modern interface?

I think, modern means only in the user interface and not in the database functionality. In terms of functionality, we do have the same things for decades - inserting, updating, deleting, committing, searching, LOVs etc. And this will remain same for a long time to come; why, because the database is almost the same for all these years and will remain same for a long time to come.

Formspider tool is what enables modern user interface. If the tool doesn't rotate the panel on the tablet the tool has to be updated to modernize the user experience. It is a functionality of the formspider.

Any way each developer has got his rich experience which dictates what is best for his users. I mostly develop for Oracle Form users and they love these facilities.

Regards.

George.

link

answered 20 Sep '15, 11:45

grajan777's gravatar image

grajan777
1011230
accept rate: 10%

edited 20 Sep '15, 12:32

Hi George,

many thanks for your explanation ! I appreciate it very much to read how you are working with Formspider. Offcourse you are definitely right on some things, such as a generic toolbar is much less work than different toolbars and it saves a lot of space.

The discussion about F7/F8 and separate search forms is as old as Oracle Forms. To be honest, i have always used F7/F8 because of all the advantages you are mentioning. Frequent users love that. But users who only work a couple of times per year with the application, do not understand it. They can understand a search button, but the can not understand that they have to press something before they can search. I am now looking for a way in between.

You have created your own "Formspider Designer", just like Michiel. You both store all information about datasources in your own repository. If i understand it correctly, the difference is that Michiel generates specific XML for every datasource with all usage flags directly implemented. You generate a general XML and use the formspider API to set these flags in runtime. I think that's a great idea. I guess you both need to make an appointment with Yalim because you both can add a lot to his product.

Kind regards, Jan Willem

link

answered 20 Sep '15, 16:15

Jan%20Willem%20Vermeer's gravatar image

Jan Willem V...
1231331
accept rate: 0%

As for XML, like Michiel I also generate specific XML for every datasource and then apply APIs for any customization based on user feedback. The difference is that Michiel generates back end code for each datasource whereas I use single set of common procedures for all the datasources put together. When a new datasource is added I need to generate only the XML. The rest is automated.

George.

(20 Sep '15, 23:38) grajan777

Hi George,

Nice to hear from you again. I hope you are doing well.

Back on topic ;-) When you say, the rest is automated, you mean that all panel and widget properties are generated automatically? I think in your application you need to add all panels/widgets and widget properties in your application repository tables in order to generate the XML. That is probably the biggest difference between your approach and mine, is that i enter all detailed panel and widget properties inside Formspider IDE using the FS XML directly (and thus feed the FS repository tables), not in my repository tables (i generate the basic XML, but modify it manually)

For me it made no sence to duplicate all Forspider widget properties in my own repository as i do not need to be able to edit these properties outside formspider. If i want to change widget properties i go into Formpider IDE, and you change the properties in your applcation, regenerate the XML and feed it to Formspider, right?

Best regards, Michiel

(21 Sep '15, 03:25) Michiel A

Hi Michiel,

Nice to hear from you. I am very happy. Hope the same with you.

I do exactly as you do. Generate the XML and copy it to FS IDE. I do not have a repository for XML. I have a standard XML for all my panels. It almost never changes. Therefore, 90% of the time I do not edit any XML manually in the FS IDE. Most of the other settings take effect at run time based values placed in setup tables for each datasource.

Eg. Label, tooltip, color, LOV etc. Since I use a single customized LOV, I need to decide as to which column will use that LOV. These settings are done once for each installation. That's all.

Consider, I have a set of four panels in a form. I generate and paste these four panels into the FS IDE. That is the only work I do with FS IDE apart from creation of datasources. Now, in my repository I specify the name of the form, panel names and location of each panel like top position, tab1, tab2, tab3 etc. At runtime these four panels will be placed on screen according to the setup. These positions can be changed without opening the FS IDE.

continued...

(21 Sep '15, 05:12) grajan777

If it is a master-detail form a relationship script is required. This is also automated as I have a single relationship script for 90% of the cases.

Other things like inserting, deleting, searching, committing etc. are all automated and do not require any additional work.

In short, for a new form, I just generate the XMLs. Copy it to IDE. Set form name and positions of the panel and that's it. Run the form from the main application menu and everything will be OK.

Regards.

George.

(21 Sep '15, 05:12) grajan777

Hi George,

That is indeed very similar as i do. For standard forms i also have standard insert, delete, search, commit etc. I have a repository structure for master-detail relationships so no need to manually code that too.

I have a single generic menubar for the master datasource (form level, with save form, save all forms, close form etc), but i chose to have specific menu's for detail datasources. I put a lot of different actions in those detail menus, so i like to have them seperate from the main generic toolbar (but ofcourse i use generic actions/procedures for doing similar stuff, like insert delete).

Best regards, Michiel

(21 Sep '15, 05:28) Michiel A

Hi Michiel,

That means every developer thinks the same way. Only a little experience is required.

The formspider company may not like this as developer involvement with FS IDE is limited. The more users work with FS IDE, the more formspider company will be benefited.

Any how, I want to appreciate the FS team for making such a great product. My special thanks to them.

Regards,

George.

(21 Sep '15, 05:36) grajan777

Hi formspider team,

I have a small request. Kindly consider the work of Michiel and try to make it part of FS for the benefit of all.

Regards.

George.

(21 Sep '15, 05:41) grajan777
showing 5 of 7 show 2 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×27

Asked: 12 Sep '15, 09:30

Seen: 2,470 times

Last updated: 28 Sep '15, 03:19


© Copyright Gerger 2017