Oracle Forms

There is no hard and fast rule but think if someone else was asked to maintain your form. Do you think it would be easy with all of these objects?
Check out http://otn.oracle.com/products/forms/pdf/bestpractices9i.pdf

Regards
Grant Ronald
Forms Product Management

thank you very much for your replay

In fact I didn't expect the form to grow so quickly
I come from C an C++ and here in a couple of weeks
I have many datablocks, canvases,program units,...
I think I am going to split the form in 4 forms just to make them easier to maintain.

best regards
alejandro

if it is on web deployment, the download time will be much longer if the form size is large. therefore, from support, from performance standpoints, the smaller the better, of course, to small you have too many files to manage too. so, the political conclusion is to make form just small enough to accommodate your business functionality while retaining the acceptable performance and maintainance level.

Actually the size of the FMB/FMX doesn't affect the download size when Web deployed, since the FMX is not downloaded to the client machine while Web deployed - it stays on the application server.
The FMX size will influence the memory consumption on the application server though. Bigger FMXs will require more memory.

What effects the download is the number of visible items that needs to be displayed.
However - I agree that you shouldn't be developing huge Forms, but rather break them according to functionality and how tight is the relationships between the activities are.

Shay,

I understand the GUI components downloading, the trigger codes will stay in middle tier, right?

When you said form not downloaded to client, you means the trigger code not downloaded to client, right?

Therefore I admit my wording not inaccurate enough, but a 'downloading' here is a common jargon though.

Actually, the graphic components are not downloaded to the client. All that the client gets is a set of meta-data instructions on which item to draw where.

This is the great thing about Form's Web architecture - you only download one applet and this applet can draw any Forms user interface just by following the instructions it gets from the application server.

More on the Forms Web Architecture is on the Forms Upgrade Center - http://otn.oracle.com/formsupgrade

Shay,

Thanks. But it seems to me this is right after forms 9i, am I right? Before 9i, it is different.

Thanks again.

John G. Feng

It is the same for 6i as well.

I think visible items isn't quite right. As far as i know it's items on visible canvases. So if you have a tab-canvas, all items on the canvas are sent to the applet. No matter if they are visible or on a hidden tabpage.

Correct. This is something that you need to watch for - there is a workaround for this if you place the items on stacked canvases that map to tabs. More on this in the tuning guide for Oracle Forms on the Web.

> understand the GUI components downloading, the trigger > codes will stay in middle tier, right?

what I am trying to do is to put all the code of the triggers in program units, or if I can, directly to the database as store procedures or functions. In this way the form is smaller and require less memory in the application server.
Also I am trying to avoid post-query triggers, using views instead (just ready to be displayed). So my forms require fewer triggers and I am not querying many times (post-queries).
Another thing that I do, is to use the where clause on the block to filter the view,
and the orderby clause I use in the block (because is a reduced set) and not on the database view

Alejandro