topic Re: Dynpros directly by methods in Application Development and Automation Discussions

Dynpros directly by methods

former_member1161170 — Wed, 21 Apr 2010 16:29:48 GMT

I have just read this interesting article, written by Thomas Jung:

"OO ABAP Dynpro Programming"

/people/thomas.jung3/blog/2005/09/08/oo-abap-dynpro-programming

If I have understood well:

1) I can't use dynpros directly by methods

2) Thomas suggests to get a dynpro by a function module, and after he can use the dynpro calling the function module

3) It isn't the faster technique (I could get everything only by the function module, without a class), but he suggests it only to get more excercises as it possible.

Are these three things correct?

Or it is possible to use dynpros directly by methods?

Re: Dynpros directly by methods

Former Member — Thu, 22 Apr 2010 07:52:22 GMT

Hi,

1) that is only correct für global classes (the ones you define with the class builder), local classes can use dynpros

directly with commands like "call screen"

2) it is a common workaround for global classes, yes

3) you could. nobody says you have to develop with oo-techniques, you can achive the same results by using classic abap

or a mixture of abap-oo and classic abap. on the otherhand. maybe check out this article about abap oo. http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/37c5db90-0201-0010-3a9b-d0a5288f3c15?quicklink=index&overridelayout=true

i agree with you that its not a good style to use a function module in oo-programming. but the classis sap gui is based on dynpros and has come a long way. for example webdynpro is completely "pure oo".

greetings,

dsp

Re: Dynpros directly by methods

former_member1161170 — Thu, 22 Apr 2010 08:38:39 GMT

>1) that is only correct für global classes (the ones you define with the class builder), local classes can use dynpros directly with commands like "call screen"

Yes. I'ts my case I'm making a global class by se24 / se80.

>2) it is a common workaround for global classes, yes

>3) you could. nobody says you have to develop with oo-techniques, you can achive the same results by using classic abap or a mixture of abap-oo and classic abap. on the otherhand. maybe check out this article about abap oo.

I'm new in Abap: I knew Java before Abap so now, if it is possible, i prefer Abap OO than Abap classic. But when I find tis limits I'm discouraged.

The article is very interesting.

i agree with you that its not a good style to use a function module in oo-programming. but the classis sap gui is based on dynpros and has come a long way. for example webdynpro is completely "pure oo".

I must work by 4.6c. I'm sure that Web Dynpros are very interesting, but they're only a dream this year.

Thanks.

Grettings.

Re: Dynpros directly by methods

Former Member — Thu, 22 Apr 2010 10:00:32 GMT

hi,

im in the same situation. i developed oo before i reached the apap world, so i was quite used to this coding-stylet. sadly there are several points where you need to go back and use classic abap elements.

maybe you could just write a small local class für dynpro handling and keep on using your global class, but i never tried this.

greetings,

dsp

Edited by: dsp on Apr 22, 2010 12:00 PM

Re: Dynpros directly by methods

sebastianNoe — Tue, 27 Apr 2010 11:55:35 GMT

Hi,

I am currently working with Dynpros in an OO context as well.

For me it was fine to define a global Interface and build up on this Interface a local class which works as a "Dynpro Handler". So my global classes can actually access the Dynpro environment and I do not have to code that much non OO Code.

Kind Regards,

Sebastian

Re: Dynpros directly by methods

Former Member — Tue, 27 Apr 2010 14:10:59 GMT

Hi,

thats a really great idea, ill try this out in my next project.

Re: Dynpros directly by methods

former_member1161170 — Wed, 28 Apr 2010 08:05:17 GMT

> I am currently working with Dynpros in an OO context as well.

> For me it was fine to define a global Interface and build up on this Interface a local class which works as a "Dynpro Handler". > So my global classes can actually access the Dynpro environment and I do not have to code that much non OO Code.

In practice it doesn't seem very different, but the style is certainly better.

I'll try to do it