International Editable SALV Day 2015

[hardyp180]

http://scn.sap.com/thread/733872

Dear Programmers,

On the 8th of February 2008 James Hawthorne started the discussion (link above) as to why SAP does not give the CL SALV TABLE the option to be editable, as CL GUI ALV GRID is.

Today is the 7^th anniversary of that blog, and hence is “International Editable SALV Day”.

I started a little discussion on this here on SCN last June:-

http://scn.sap.com/thread/3567633

Back in the year 2003 I went to SAPPHIRE in Brisbane and the speakers from SAP made much of the convergence of reports and transactions.

To put that another way – people did not just want a list of blocked sales documents where the system could not determine the price. They wanted a list of such documents on a screen where you could actually change the price yourself to fix the problem, and then release the document there and then.

The obvious answer is an editable grid, rather like the table controls in classical DYNPRO.

In CL_GUI_ALV_GRID this was a piece of cake. You could set whatever cells you like to be editable, and programmatically add extra custom commands at the top of the screen e.g. a custom “release” button.

The CL_SALV_TABLE was supposed to be the successor of CL_GUI_ALV_GRID and SAP pushed us to use that instead. Whilst far better in many ways, CL_SALV_TABLE has some surprising drawbacks, making it actually have less functionality than its predecessors.

·         You cannot edit the data

·         You cannot programmatically add commands in the full screen mode

·         You cannot add separator lines between icons

All of this was available in CL_GUI_ALV_GRID. The really strange thing is that at the heart of a CL_SALV_TABLE instance is a a CL_GUI_ALV_GRID instance, so obviously all of the above functionality could be added if it was so desired.

You will see from the prior blogs that the history of this is as follows:-

·         Every single ABAP developer desires this extra functionality in CL_SALV_TABLE

·         Many workarounds have been proposed on assorted SCN blogs

·         SAP development looks for those workarounds, and changes the CL_SALV_TABLE to block them

·         People tried to do the right thing, and put a proposal on “idea place” to make the SALV editable, a proposal which got a lot of votes

·         A senior SAP person from the development department got very upset indeed, said the SALV was never meant to be editable, and closed off the idea.

To quote from “V for Vendetta” however you cannot kill an idea.......

So eight years on and workarounds are still springing up. SAP development can close off certain avenues but with the enhancement framework it is possiblefor developers to get around virtually any barriers placed in their way.

Wouldn’t it be easier if this was not a fight between the central team at SAP who develop the ABAP language and the users of that language?

Someone once said that if there was a law, and virtually everybody broke that law on a day to day basis, would it not be worth looking at the law to see if it actually made sense?

I don’t mind admitting I have created several SALV reports in my company where the users can edit data and I imagine I am not alone. I am also sure SAP development would be horrified by this fact. They hate people doing workarounds, cannot fathom my anyone would do such a rule-breaking dangerous risky thing, just to keep the business users happy.

As I said at the end of my last posting on this subject might I humbly suggest to the red nosed SAP ALV development team that the easiest way to stop people doing workarounds is to remove the need for a workaround in the first place, by having the functionality as standard.

So the question is – in 12 months’ time will I be posting another blog to celebrate the 9^th anniversary of International Editable SALV Day?

Cheersy Cheers

Paul