Hello everyone - Good afternoon. First of all, I am new to FS, still trying to learn the basics and so far the learning experience very good.

I always try to break bigger tasks into small chunks and try to combine them to make a bigger one.

I have a question, how to break my bigger application into smaller ones.

Lets say I want to create a small application say "Contact us", that has a panel that has few text boxes, list item (It looks like we call them as "Combolist") and a data source that we insert the data into a table.

I would like to make this as a "Component" and include on other applications. Is it possible? Am I thinking right? If we can do this, how? Thank you for your help on this.

Happy FS :)

asked 26 Feb '14, 18:38

viswapsp's gravatar image

accept rate: 11%

Hi Viswa,

What you describe, having different application 'modules' that can work together at runtime, is currently not possible with Formspider.
The same question is asked when i started working with formspider, here:

The application we are building with Formspider now has about 1100 panels and about 400 datasources and i must say is is still very well manageable and fast. The only thing is to think of a good naming convention and stick with it (for example prefix all the sources that belong to the same 'application' with the same prefix.. that way you can easily restrict the view on panels/datasources etc.)

Sure, modularity would be very nice to have in Formspider (and my guess is that it will one day be available), but not having the possibility has not been a problem for me so far.

Have fun,
Michiel A.


answered 27 Feb '14, 15:29

Michiel%20A's gravatar image

Michiel A
accept rate: 13%

Michiel - Thank you very much. Its good to know that even with bigger size it is still fast and manageable.

Please let me know if I understood correctly -

  1. if there are two FormSpider applications, and both of them need a "Contact us" screen, each one of the applications need to have one panel, one data source, and whatever the number of text fields etc.

  2. The number of objects (1100 panels and 400 data sources) - Do they belong to ONE application?

  3. Though I am very good at naming convention (and standards), do you have a standard list that is working for you? Is it possible to share it? So far I was thinking to leave the first 2/3 characters followed by an underscore, for the type of the component. For example -

tf_customer_name -> text field; tl_customer_name -> text label; dg_customers -> datagrid; ds_customers -> data source; tpl_customer_quid -> tabbed panel for query, update, insert and delete; sml_customers_qi -> simple pannel for query and insert; spl_customers -> split panel;

(11 Mar '14, 16:56) viswapsp

Hi Viswa,

i will give the answers to your questions as a new answer.. i need some more space ;)


(12 Mar '14, 07:12) Michiel A

Hi Viswa, Here are my answers to your questions

1 Correct. At this point in time, each Formspider Application is completely independent of each other, so you have to duplicate the panels and datasource.

2 The 1100 panels and 400 datasources (so far) belong to the same Formspider application, but logically, these are broken down into 3 applications. You will see 3 main menu options in our menu tree for each 'module'.

3a. Naming convention for panels:
Each application 'module' (contained in the same Formspider application) has a 3 letter code. For example we made an framework/authorization application which has a 3 letter code 'AUT'. Since we have a 'Form' structure where each 'Form' starts in a new tab page we have 1 main outer panel for each form. Each form has a code (we come from Oracle Forms where we had the same structure). The form code is
[3 letter application alias][master table 3 letter abbreviation][3 digit sequence number]

For example AUTFRM010 . So this AUTFRM010 is the prefix for each panel that belongs to this form. Ech panel then gets a logical name within the form structure, for example

alt text

This works out for me. It keeps your panels organised in the panel tree.

3b. Naming convention for components:
We just use the same name as the datasource column if it is bound to a datasource, otherwise we just give it a logical name if neccesary. (Naming convention for panels is much more important)

3c. Naming conventions for datasources:
We just follow the datasource tabel or view name here. To datasources for lists we add a _list suffix to indicate it.

Good luck,


answered 12 Mar '14, 07:22

Michiel%20A's gravatar image

Michiel A
accept rate: 13%

edited 12 Mar '14, 07:24

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: 26 Feb '14, 18:38

Seen: 1,790 times

Last updated: 12 Mar '14, 07:24

© Copyright Gerger 2017