Hello Yalim, originally I ve asked this question here: http://osqa.theformspider.com/questions/1146/returning-to-the-calling-application-from-the-called-application but then I realized that I posted an "answer" not a question - so moving to new topic.

we are looking for the best way to convert our Oracle Forms to something more up tp date and the formspider solution looks very inspiring at the moment. But there are some concerns as well. Am I right that if we have for example 8 heavy forms - we need to join them in one application? I have some concerns regarding the scalability and the final "weight" of this application. Could you please also share a link to huge application you mentioned above for us to check the way how it works? My email is hotspot163 at yahoo dot com

So far in our case we would prefer to build 1 separate application per heavy form and call them via the global menu. But in this case we have not find the way how to use one default Oracle forms menu for each application as in formspider the menu is not a separate module as it is in Oracle Forms. So we can't "add" it to the application and reuse it. Instead we need to copy-paste the code which is not a nice solution. Also I noticed this topic as well from Mar20 http://osqa.theformspider.com/questions/190/application-size-reusability Are there any changes from that point?

Probably our concerns regarding "one form - one application" can be disregarded - that's why I m trying to get an answer in this forum.

Thanks in advance and looking forward to hearing from you.

Best regards, Anatoly

asked 12 May '13, 06:39

anatoly4u's gravatar image

anatoly4u
6914
accept rate: 0%

edited 12 May '13, 15:48


Hi Anatoly,

Great question. Let me go over your comments one by one and answer them:

Am I right that if we have for example 8 heavy forms - we need to join them in one application?

Yes. For now anyway.

I have some concerns regarding the scalability and the final "weight" of this application.

There are no problems regarding scalability if a Formspider application is big. This is the hardest mental shift we are facing. from developers. It is so buried deep in our DNA that if an application is bug it must be slow, therefore it needs to be divided into smaller pieces to perform well. This is not without reason. This is pretty much how every other development tool works. When applications get bigger, developers must divide them into smaller pieces otherwise the apps collapse under their own weight.

This is not the case with Formspider. Formspider streams applications to the client. It only initializes parts of an application that is either referenced by code or called by the user. In formspider the performance of an application is independent of its size. You can have an application with 10,000 screens. There is no reason for it to be any slower than a 10 screen application.

So in Formspider there is no reason to divide an application to make it scalable.

With that said, there may be other reasons for dividing applications into smaller pieces. It is perfectly reasonable to divide a system into logical pieces from a business perspective (for example, maybe you are an ISV and you do not want to deploy modules to the customer that the customer didn't buy).

We want to build an application development framework that does not force you to divide your system into pieces for technical reasons (performance is one of them). Developers should only divide their system into pieces for business reasons. We are not 100% there yet but this is where we want to go.

So today, your best solution is to build a single application for your 8 forms. In the future, you will be able to divide these applications to 8 if there is a business reason to do so. And dividing an application in Formspider will be very easy. Everything is stored in relational tables. It will be just a few update statements to move your screens from one app to the other. Virtually all of the code will continue to work the same way. You will attach the small applications to the main one as libraries.

Could you please also share a link to huge application

Sure. Here is one: http://formspideronline.com/i2/main.html?name=IBEX_V2

This is a budget and finance application built with Formspider. It has 7 logical modules and around 1000-1500 Panels in total, if not more. The entire system is implemented as one application. Feel free to play with it. I'll email you the link of its IDE so that you can look at its screen definitions. I will send the email in the next few hours.

Hope this helps.

Kind Regards, Yalim

link

answered 13 May '13, 04:54

Yalim%20Gerger's gravatar image

Yalim Gerger ♦♦
1.8k5
accept rate: 15%

Hello Yalim, many thanks for helpful answer! Sure I will look to IDE when I get the link. thanks again

(13 May '13, 05:34) anatoly4u

Hi Anatoly,

I emailed you the link of the IDE.

Regards,
Ibrahim

(13 May '13, 07:07) Ibrahim Sand... ♦♦

Hi Anatoly,

Maybe i can share my experience developing with Formspider for the last year. I was the one that asked the question about application size an reuse that you mention, so i had some of the same questions as you have.

My experience until now is that the size of a Formspider is technically not an issue. As Yalim said, when the application starts, it only loads the things you need for your first screen. The rest will load when you need it. So it does not matter hoe large the aplication gets, it will perform the same. It is not that you will have to compile a module or something, as in Forms.

Another issue is when you build a big application with hundreds of datasources and panels, in the IDE the list of panels, datasources and other objects will obviously grow larger and larger as you go. I have now about 300 datasources and 900 panels in my application, and the only thing you want to think of is good naming conventions for you panels and datasources. When the number of objects grow, you will use the filter field in the IDE to restrict the list to the panels you need for the task you are working on, so naming conventions really help a lot in keeping the overview.

So for example, if you want to 'divide' the application in 8 modules, just start all panels with the module code, like 'mod1', 'mod2' and so on. Probably these modules consist of several screens, so you maight then have a second part in your panel name , being the screen code, for example, 'scr1'. The screens in Formspider will contain multiple panels, so what you end up with in your list of containers could look like:

mod1_scr1_panel1
mod1_scr1_panel2
mod2_scr1_panela
mod2_scr2_panela

and so on...

This way you can easily filter on 'mod1' and it would work just like you have only 1 module in the application.

Dividing the aplication in more pieces for other reasons, like deploying modules to customers or developing generic modules, would be very nice to have. When later on, this functionality is added to Formspider, it would be very easy to split the application up in pieces again.

Good luck, and have fun developing,
Michiel A.

link

answered 13 May '13, 06:27

Michiel%20A's gravatar image

Michiel A
5161544
accept rate: 13%

edited 13 May '13, 06:36

Thanks Michiel! It is nice to be kind of on the same page. In my opinion the FS app is already a very good and valueable product though I would be really interested if I could get a kind of a roadmap of features planned to be released at 2013

(13 May '13, 06:49) anatoly4u
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:

×6
×3

Asked: 12 May '13, 06:39

Seen: 1,132 times

Last updated: 13 May '13, 07:07


© Copyright Gerger 2017