Why Dialog Programming is also called as Module Pool Programming?

[Former Member]

Hi,

Why Dialog Programming is also called as Module Pool Programming?

Thanks & regards,

Gopi.

[abdul_hakim]

hi

this is becoz the code which you write in dialog programming is enclosed between MODULE..ENDMODULE hence

structuring your ABAP Code in to modules...

Cheers,

Abdul Hakim

[RichHeilman]

The reason is because a dialog program is usually developed by creating a module pool program. A module pool program is a program type which is not executable directly. You can not just run by hitting F8 like a report program. You must tied a tcode to a screen in order to start the program. Module pool programs usually have 4 or more include programs inside the main one. One for TOP, which has the top declarations, I01, for all of the PAI modules, O01 for all of the PBO modules and F01 which has the FORMs. You create screens inside your module pool program then link them to tcodes.

Regards,

Rich Heilman

[Former Member]

Hi,

Screens call dialog modules in the associated ABAP program from their flow logic. Type M programs serve principally as containers for dialog modules, and are therefore known as <b>module pools</b>.

Hence Dialog Programming is also called as Module Pool Programming.

Regards,

Azaz Ali.

[Former Member]

Hi,

Dialog Programming consists of screens and corresponding ABAP program. The logic behind the screen is written in the ABAP program enclosed between MODULE...ENDMODULE statement. ABAP program consists of no of such modules which can be called from any screen. Hence its calls as Module Pool programming.

[Former Member]

hi

good

In the Object Browser, the module pool code belongs to one of the following categories:

Global fields: data declarations that can be used by all modules in the module pool

PBO modules: modules that are called before displaying the screen

PAI modules: modules that are called in response to the user input

Subroutines: subroutines that can be called from any position within the module pool

By default, the system divides a module pool into one or several include programs. An include program can contain several modules of the same type (only PBO modules or only PAI modules). The main program then consists of a sequence of INCLUDE statements that link the modules to the module pool:

GO THROUGH THIS LINK FOR DETAIL

http://sap.mis.cmich.edu/sap-abap/abap09/sld011.htm

THANKS

MRUTYUN

[Former Member]

Hi Gopi,

Each dialog in an SAP system is controlled by dynpros.A dynpros consists of a screen

And its flow logic and controls exactly one dialog step.

- ABAP/4 module Pool.

Each dynpro refers to exactly one ABAP/4 dialog program .Such a dialog program is also called a module pool ,since it consists of interactive modules.

reward if it helps

regards,

keerthi

[Former Member]

The reason is because a dialog program is usually developed by creating a module pool program. A module pool program is a program type which is not executable directly. You can not just run by hitting F8 like a report program. You must tied a tcode to a screen in order to start the program. Module pool programs usually have 4 or more include programs inside the main one. One for TOP, which has the top declarations, I01, for all of the PAI modules, O01 for all of the PBO modules and F01 which has the FORMs. You create screens inside your module pool program then link them to tcodes.

[uwe_schieferstein]

Hello Gopi

The most frequent transaction types are <i>report transactions</i> (calls the selection screen of a report) and <i>dialog transactions</i> (calls the start dynpro of a module pool).

Module pools are, like reports or function groups, a certain kind of organizing the parts of an application (as described by Rich Heilman).

An interesting question is: <i>"Should you develop your dialogs as module pools?"</i>

My personal answer to this question is: I developed a few module pools in my early days but nowadays I do not use this program type anymore. Why? Because it does not follow the <b>MVC</b> (model-view-controller) architecture that I try to apply to my dialogs.

In a module pool (and in reports as well) everything is <i>clustered</i> together, the handling of business data (model), the presentation (view; selection-screen, dynpros) and the handling of user-commands (control; usually implemented as PAI logic in dynpros).

How do I implement my dialogs? Usually I have at least three classes, a controller, a view and a model. The dialog is started using an OO-transaction which calls method MAIN of the controller.

Selection-screens and dynpros are placed in function groups. If I have only controls on my dynpros there are almost no elements on these dynpro nor do I implement any logic in the dynpro. The container(s) holding the controls (e.g. ALV list, tree) are simply linked to the dynpros before displaying them.

The main advantage that I have from this architecture is a higher flexibility. For example, if I want to display an ALV list on a different dynpro in a different application I simply re-link the container references that I get from the view class to this new dynpro? Can you do the same with dynpros in module pools? The answer is "no".

To summarize: module pools are in my opinion (based on MVC principles) not the best choice to develop dialogs.

Regards

Uwe