I am evaluating Formspider the last couple of days and i must say that i really like what i've seen so far. I am an Oracle Forms / Oracle Apex developer and i find Formspider very easy to use once you get a hang of the basic structure.

But being a Formspider newbie now i have some questions i like to ask. First one is is a generic one and is about application size and reusability.

My company has build a reasonably large Oracle Forms application over the last years. It consist of about 1100 forms and 350 reports. The database has some 1050 tables (not counting the journal tables). We use Oracle Designer and generate 100% of our forms through Designer. To keep things manageable we have split the application in about 20 'Application systems' (modules). Each application system has its own database schema. Some of these application systems hold generic functionality for one or more other applications systems, like master data, authentication/authorization, report definitions etc. In Oracle designer you can use forms or module components between application systems. So one can create generic (parts of) forms in one application and use it in another.

Say we would like to use Formspider to rebuild this application, how would you approach it? As far as I have seen, i cannot for example include panels from another application. Putting everything in one application i think would be theoretically possible, but the number of datasources, panels, actions etc will be in the thousands. I saw the possibility of exporting/importing parts of an application, so you could build in one application and export to the others, but i dont think that's a perfect solution to manage.

What would be best practice in this case? Are there any products of this size already built with Formspider and how were these managed?

Thanks, Michiel

asked 19 Feb '12, 14:48

Michiel%20A's gravatar image

Michiel A
accept rate: 13%

Hi Michiel,

Thank you for your kind words. You asked some very good questions. Below are my answers;

There are several big applications built with Formspider with hundreds of panels and datasources. You can read the story of the biggest one here. This application has 3093 panels and 1181 datasource definitions.

The story of another smaller one is here. And here is the URL of the application for you to look at it.

Finally, one of the largest application we built can be viewed from here. It has 1456 panels and 365 datasource definitions. I will send you an email with the user name and password so that you can access it. I will also provide you access to its source in the email.

As you correctly mentioned, technically there is no reason (performance or otherwise) not to built one Formspider application with thousands of datasources and panels etc...(which is pretty amazing in its own right given that many technologies cannot support this many objects) However, as you pointed out, there might be the practical problem of managing many objects even though managing thousands of objects is easier in Formspider than in Forms or APEX.

You are correct that Formspider does not have a way to logically group objects in an application and reuse them in a different one. The lack of this feature was never painful enough for us to justify its implementation at least until today. I wondered how the teams worked with many objects in their Formspider applications. So I did a little survey. Here are my findings;

1) The application was big but the objects in it had little or no use outside of its scope. So for example, the team built a big financial application but there was nothing in it that they could reuse in another application.

2) Code was already reusable because it was all stored in the database available for any application.

3) There is no technical limitation that forces the teams to divide the application.

4) The teams used the filtering capabilities of the navigation trees in the IDE and good naming conventions to find the objects that they are working on. For example the datasources relevant to accounting where prefixed with ACC_. The panels that were used in the budget module were prefixed with BDG_ .

5) The structure of the source, hence its management, deployment, and integration became significantly easier.

I think the point I am trying to make is that the size of an application is less of a problem in Formspider and our users did not perceive this as a problem until today. On the contrary, they are quite happy with the simplification of having one application.

However, we understand the benefits of multiple applications as well. We want our users to have the option to divide their applications into modules if this is what they prefer. This is a feature we are planning to implement. We’d be happy to work with you and deliver the feature set you need, long before the size of your application becomes a problem.

I hope this helps answering your questions. Please don't hesitate to ask any question you might have. We'd be happy to help.




answered 20 Feb '12, 09:05

Yalim%20K.%20Gerger's gravatar image

Yalim K. Gerger ♦♦
accept rate: 20%

Hi Yalim,

Thanks for your extensive answer. It's great to see what has been built already and being able to look at some real life app source code would be great!

I think that having good naming conventions in place (prefixing all objects with a 3 letter module prefix is what we currently are doing in Oracle Designer as well) and using the filter options would probably be a viable option. (maybe its an idea to put a 'global' filter option in the Formspider IDE next to the 'Application' selector to be able to filter all options at once.. i know i'm lazy ;) I think the only way to know if in the long run its gouing to be problematic is to start building this 5000 panel application and experience it...

For now i'm having great fun evaluating Formspider and will probably bug you with some more questions over the next days. Keep up the good work!



answered 21 Feb '12, 02:06

Michiel%20A's gravatar image

Michiel A
accept rate: 13%

Your answer
toggle preview

Follow this question

By Email:

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



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



Asked: 19 Feb '12, 14:48

Seen: 3,411 times

Last updated: 21 Feb '12, 06:47

Related questions

© Copyright Gerger 2017