Can you loop on a deep-structure itab within Smartforms?

[Former Member]

I know that Smartforms lets you pass a table to Smartforms and that you can loop on this itab.

But suppose the itab has deep-structure - each row has another itab in it.  (This is common, for example, in APO.)

Then within the outer loop on the outer itab, can you loop on the inner itab within each row?

Thanks for your kind advice here.

[Former Member]

So long as you code the Smartform accordingly then nested tables are not an issue. Yes they can be handled.

Che

[che_eky]

So long as you code the Smartform accordingly then nested tables are not an issue. Yes they can be handled.

Che

[Former Member]

Thanks very much for replying so quickly, Che.

But here's one thing I don't understand.  If you can do nested loops in Smartforms on itabs within itabs, then why is there so much discussion of how to do "control- breaks" in smartforms????

With deep-structure itabs (itabs within rows of itabs), you can set up the control-breaks outside smartforms and there is almost nothing left to do inside smartforms!!!!!

[che_eky]

Oh boy, in my experience, there is always lots left to do in side the smartform! I am not sure what you are trying to prove, what does it matter if the control breaks are on the outer or deeper tables?

Che

[matt]

I suspect one reason might be that many programmers seem to find nested tables (along with hashed tables, data references, inner joins...) rather scary.

The smartforms I've created from scratch have one main variable - an object reference. Everything else comes from that, which means that the amount of coding in the smartform (where it is harder to find, harder to debug and version management doesn't work) is kept to a minimum.

[Former Member]

Che - Judging from your response, it seems that you don't think you ever need to be concerned about performance.

Are you aware that there are many shops which PROHIBIT developers from putting any code inside smartforms except very trivial little bits of formatting business?

Why do you think they enforce this prohibition?

[Former Member]

Thank you very much for that response, Matthew.  In my opinion, it is 100% correct - the code that does the "heavy lifting" should stay OUTSIDE smartforms.

And yes, I agree - most programmers still handle itabs like they were handled ten or even twenty years ago.

Do you know how many EXPERIENCED developers aren't even aware that SAP no longer officially supports the BINARY SEARCH clause in itab READS?  (Because SAP wants you to predefine the table as SORTED either instream or in the dictionary.)

And as I'm sure you're aware, the only drawback to defining itabs as SORTED or HASHED instream or in the dictionary is if you have to insert rows - then you can't append initial line to the itab, because when you try to fill the row, you get the "can't modify key" error, of course.

But for itabs that only need to be read, this problem never occurs ...

[matt]

David Halitsky wrote:

...

Do you know how many EXPERIENCED developers aren't even aware that SAP no longer officially supports the BINARY SEARCH clause in itab READS?  

I moderate this part of the site so I'm very much aware of the level of ignorance among many developers - some even using really obsolete stuff, like ON CHANGE.. 

When I catch it, I deal with it.

[che_eky]

David,

I do not appreciate the tone of your response. Saying that I don't think ever think to be concerned about performance is without proof or foundation. If you want to pick a fight I suggest you start your posts "I want to pick a fight".

I clearly answered the very basic question you asked "can you loop on the inner itab within each row".

Che

[Former Member]

Yes, you answered my first question correctly, Che, and I politely thanked you for that answer, AND gave you credit for a CORRECT answer.

Regarding the second part of our interchange, I apologize if I leapt to a concluson.

So - why don't you help us out here by putting an upper-limit on what you yourself allow yourself to code inside a Smartform.

For example:

Will you yourself code a control break sequence inside Smartforms?

Will you do select singles out to a database table from inside Smartforms, instead of doing a for all entries up front, and passing the itab to the form?

[che_eky]

David,

My comment "there is always lots left to do in side the smartform" pertains to the formatting of output into a form acceptable to the user requirements. NOT filling it with mulltiitudes of code as you seem to have thought.

There are many instances where code in side of Smart forms is the smart thing to do.

Che

[Former Member]

Matthew -

When I say I am so glad that you are an SCN subject-matter moderator who stays up-to-date with his subject, I really mean that.  SInce joining SCN ten years ago (then SDN), I have encountered some moderators who think the way they learned things in 1998 is still the way to go.

It's like my uncle told me - he went to Geneva in Switzerland on the US GI Bill after WWII for his MD degree, and he told me there were professors there who were still using true animal gut for stiching, because they didn't want to switch to "newfangled" synthetics.

So good for you - keep fighting tne good fight! And if you ever get weary, just remember the tasks of poor Hercules - particularly the task that involved cleaning the Augean stables.

[Former Member]

Che -

You wrote:

"There are many instances where code in side of Smart forms is the smart thing to do."

And we would be in complete agreement if you would just change that to:

"There are many TRIVIAL  instances where TRIVIAL code inside of Smart forms is the smart thing to do."

Of course, we may differ here in our definition of TRIVIAL, and even more importantly, what kind of code is even worth talking about.

To me (and probably anyone else who has been in the business for a long time), ANY kind of formatting issue is trivial.

That's why it didn't occur to me that you might be talking about formatting when you talked about "lots to do inside smartforms".

Frankly,I don't even think about code for Smartform formatting anymore, because the companies I work for have realized a long time ago that such code should be out-sourced to people who are making a lot less than I am.  Just like simple screens for hand-helds, etc.

[che_eky]

David - Judging from your response, it seems that you have never developed anything more than the simplest of Smartforms.

[Former Member]

Hi Che -

I think we should respectfully agree to disagree on whether any code INSIDE a smartform should ever be considered as anything other than trivial code.

The reason I say this is because I still remember something a very wise professor told me many years ago:

If you tell people they are merely mistaken, they will generally forgive you.  BUT, if you tell people they are fundamentally misconceived, they will NEVER forgive you.

However, if you think you can teach the community something here, then by all means, let's continue the discussion.

Give us an example of some NON-TRIVIAL formatting code which you yourself have put inside a SMARTFORM ...

[che_eky]

David,

I respectfully do not have the energy to continue this discussion. Not unless you keep prodding and provoking me as you have been

Suffice to say that I have never seen a problem with code in Smartforms. At the end of the day

inefficient code is inefficient code, whether it be in a smartform, sap script include, report, module pool, function module, class method or any other carrier.

There are no custom smartforms on the system here otherwise I would maybe have dragged up some code for you. Mmwahahahaha!

Che

[Former Member]

Come on now, Che - I clearly wasn't asking for an actual code sample - just what IBM might call an HLD of the "non-trivial" problem to be solved.

But if nothing comes readily to your mind that you can simply explain in a few words, then please be assured I am the last person who would ask you to exert yourself in this regard ...

Finally, it's true what you say that inefficient code can be outside smartforms as well as inside.

But surely - you understand that in general, it's probably easier to obtain efficiency OUTSIDE smartforms anytime the problem is sufficiently non-trivial that the question of efficiency even arises in the first place.

If you don't feel like responding, I completely understand ... go in peace, be good to yourself, and may the road rise to meet you!!

[chaouki_akir]

Bonjour,

And as I'm sure you're aware, the only drawback to defining itabs as SORTED or HASHED instream or in the dictionary is if you have to insert rows - then you can't append initial line to the itab, because when you try to fill the row, you get the "can't modify key" error, of course.

I am trying to understand but I do not. Can you show in small example program how to get the error "can't modify key"  ?

[Former Member]

Hi Chaouki.

Are you Lebanese? At NYU many years ago I knew a Chaouki Chamoun from Lebanon - I think he became a famous artist.

Anyway, do the following:

1) Make this throw-away program as a local object in SE80:

* Declarations

* you should learn to PRE-define the sorted itab with primary key directly in SE11, if you don't already know how to do that

* of course, this will require pre-definition of the TYPE in SE11 first.

TYPES:

  BEGIN OF gtyp_0001,

    pernr                TYPE persno,

    begda                TYPE begda,

    endda                TYPE endda,

    kostl                TYPE kostl,

    persk                TYPE persk,

    ansvh                TYPE ansvh,

  END   OF gtyp_0001.

FIELD-SYMBOLS:

  <gfs_0001>             TYPE gtyp_0001.

DATA:

  gt_0001             TYPE SORTED TABLE OF gtyp_0001

                           WITH UNIQUE KEY PRIMARY_KEY

                             COMPONENTS

                               pernr.

* Code:

* this line will create an "all-blanks" primary key value in the btree index for the table

  APPEND INITIAL LINE TO gt_0001 ASSIGNING <gfs_0001>.

*this line will try to change the "all-blanks" primary key value to '1234567'

  <gfs_0001>-pernr = '1234567'.

2) Now execute the program.

What happened when you executed the program ????

[Jelena_Perfiljeva]

Is this really The David Halitsky or did someone hack into your account?

It's easier if you're also writing your own program to call the form. If you're working with standard output (95% of the time for me) and have to customize the form anyway then why the heck would I customize the output program too? If we keep at least standard output program then (1) we get at least some support from SAP; (2) one less thing to worry about during upgrade.

If someone writes their own program to call the form and puts SELECT in the form then yeah, it's just stupid. But when you step into the standard territory it's not that black and white, unfortunately.

[Former Member]

Hi Jelena - yes, it's me.  Who else would it be (as my Polish grandfather might say?)

I understand the point you're making about the trade-off between bastardizing an SAP standard output program versus stuffing a Smartform with code like a goose for pate de foie gras.

BUT - from my experience with customizing all kinds of standard output programs, I know that there is a "separation of layers" approach to this problem which will let you add the customization you need, but still stay out of the form.

Here's the approach - in my experience, it can generally be made to work and work well.

1) find the place where the standard program calls the form.

2) find the last possible moment before that where you can stick an enhancement - this has to be a place AFTER SAP has constructed everything it's going to pass to the form; also, you must choose this enhancement point so you can do your own call to your own form function module, and then exit before the standard SAP call to the form function module.

3) see what else the form needs that the standard SAP output  program has not collected at that point

4) gather it in the enhancement.

5)  call your form function module with what SAP has collected and what you have collected.

[matt]

Jelena Perfiljeva wrote:



If someone writes their own program to call the form and puts SELECT in the form then yeah, it's just stupid. But when you step into the standard territory it's not that black and white, unfortunately.

Looking at the smartform I last wrote (four or five years ago), I see that this is exactly how someone has enhanced my smartform... 

[Jelena_Perfiljeva]

David, the fields that are looked up in the form normally are not part of the form's interface, so how would you pass data to the form - enhance the interface structure as well? That's exactly where adding code in the form is starting to look more appealing by the second.

[Former Member]

Adding code in the form may look appealing, JP.  But as you know, appearances are deceiving.

Transfer the question to a different context, and you'll see immediately that calling your own form FM with an enhanced interface is precisely the way to go.

Ask yourself how many ABAP Webdynpro programmers run into trouble because they don't do things in controllers, but lower down in windows etc.

Same exact thing here ... exact same thing ... remember "separation of layers"

"Output" is another word for "presentation", and you DON'T mix presentation and process layers without asking for trouble ... and typically getting it.

But, I'm glad you're happy with your own point of view on this matter, as your happy face seems to indicate.

What is the old saying ... ignorance is .... what?  That's what I love about happy faces - they're so blissful ....

[Jelena_Perfiljeva]

David, separation of concerns is not the law of physics like gravity that is valid no matter what you think about it, it's a design principle. And personally I'm a big fan of another principle - KISS.

As I said, it's not all black and white specifically with the forms. If someone needs to add horse loads of code then by all means knock yourself out with the enhancements. But if, for example, we need to add 4 lines of code for two fields in the invoice form (I honestly don't understand why customer's phone and email are not included in the standard interface) I would not recommend anyone to invest in enhancing and documenting 3 objects just for the sake of getting "I separate the layers" bumper sticker. It simply does not make any sense because you won't be able to get any benefits associated with separation and it will actually be more difficult to maintain. E.g. one program may be used by different forms. Some field may only be needed in one form. If you put it in the program then either you'll have a code there that is redundant or you'd need to find some way to ensure it only works for one form. Then you also have to do the regression testing for all the forms. So all this headache and for what benefit exactly? In 5 years we haven't made any changes in the form that could've benefitted from "separate layers" and I don't see us doing that until there is some next generation of forms.

I believe "know when to hold 'em and when to fold 'em" applies to some principles too. One needs to evaluate a specific task and understand pros and cons of doing it one way or another. Principle is only as good as the value it adds. No matter how great it is in theory.

We already had very similar discussion on OOP. The consultants immediately tend to think about some large scale development ("stuffing the form" in this example). But it is not always the case. You might think that I'm just blissfully clueless of some potential catastrophic results that such approach may bring, but I can assure you that if you mention at least one specific risk (and Webdynpro doesn't count) I can show you how it is not relevant in the specific cases.

[Former Member]

Hi again JP -

I'm sure you remember the difference between Christ's "Hypothetical Imperative" and Kant's "Categorical Imperative"?  

Your approach clearly fails the crucial requirement imposed by the latter.

Best as always

djh

[Jelena_Perfiljeva]

It's a major bummer that these days the widespread use of Wikipedia and Google makes it more and more difficult for the fancy intellectuals to disguise an insult as a clever philosophical reference.

By the way, the code sample does not compile (no PRIMARY_KEY field) - is this 7.4 syntax or a typo?

[Former Member]

I just recompiled it again and it compiled fine.

My system status panel says

SAP ECC 6.0

I don't know how you would interpret that.

Are you sure you have the word "pernr" after the keyword COMPONENTS in the definition of the itab?

[Former Member]

And no, there was no insult intended. 

I was merely pointing out that if everybody on your system took your approach with every form, the overall performance of the system would NECESSARILY degrade because many folks are doing repeated SELECT SINGLE's against the database.  And of course, once you open the "barn door", it's quite possible that many people would do more than one SELECT SINGLE within the same form for different reasons, which would compound the performance problem even further.

Please don't tell me you're going to disagree with this obvious fact.

If you do, then I have to assume you're fairly young, and therefore operate under the assumption that it's cheaper to throw hardware at performance problems than to teach developers to stop coding like their program is the only program running on the system.

[matt]

I think we are now way off topic. Perhaps this could be continued in the Coffee Corner.

I'll lock the thread now.