International Editable SALV Day 2018
Year TEN
Dear CL_SALV_TABLE Fans,
Welcome to February 8th, 2018 which is the tenth International Editable SALV Day. See below for a link to a blog I wrote to celebrate this day exactly one year ago:-
https://blogs.sap.com/2017/02/08/international-editable-salv-day-2017/
There is no problem going on and on about the problem. The CL_SALV_TABLE was supposed to e better than the CL_GUI_ALV_GRID but really it was not as it had less functionality.
To sum things up – opinion is divided here – every single customer of SAP wants the SALV_TABLE to be editable, but SAP says no all of you do not actually want that, you do not know what you want, you foolish fools you.
This day marks the 10th anniversary of James Hawthorne going cap in hand to SAP and suggesting maybe the CL_SALV_TABLE could be brought up to functional parity with the CL_GUI_ALV_GRID and have an option to be editable.
http://scn.sap.com/thread/733872
It took a while but we have all come up with the answer – have some sort of wrapper, and use CL_SALV_TABLE for the one thing it is good at – generating field catalogs from internal tables – and then use CL_GUI_ALV_GRID for everything else.
All well and good even if that does not really address the issue of how new versions of CL_SALV_TABLE like the one with :integrated data access” are going to work. Are they going to be editable? I suspect not.
The problem is that is the nature of human beings to justify a decision they have made, no matter how much evidence is presented to them after the event.
In this case the decision was “do not design this to be editable, it would add a lot of time to the development, and most likely no-one wants it anyway, based on a survey of zero people I have done”. Thereafter when the original decision is challenged on whatever grounds the answer comes back the answer comes back “the original decision was RIGHT and you are a MORON”. If you click on the link at the top and work back through the history of this discussion you will see the head of ABAP development at SAP at the time (many years back now) pretty much saying exactly that.
We still have seven years till ECC 6.0 support runs out, and I would not die of shock if SAP decides to extend that, so there is still plenty of life left in the old ALV grid yet.
This particular feature (or lack of a feature) is never going to change, which is not to say I am going to stop moaning about it on this day every year.
Once upon a time SAP had a concept called “Idea Place” where the community got vote for mssing functionality like this. Someone put up the idea of having an editable CL_SALV_TABLE and the votes started coming in thick and fast so SAP (at the time) made the idea non-editable (very ironic) and then deleted it. That was not the sort of idea they were looking for. You are only allowed to have certain types of ideas.
I suppose the difference this year is now I am an SAP Mentor, and I understand that one of the jobs of SAP Mentors is to gather up all the moans and complaints from the SAP community and lay them at the door of the SAP executives at events like TECHED.
I was actually in the same room with Sam Yen, head of UI things at SAP in the Las Vegas event last year. The question is – would I have been laughed out of court if I had started talking about the ALV when 99% of questions were about UI5 and artificial intelligence chat-bots like “co-pilot” and so on?
Next time I think I will bring it up anyways, even if I am tarred and feathered as a result.
OK, each year there is less to say about this, as everything has been said before, but I will be back next year to say it again.
Cheersy Cheers
Paul
Happy (or should i say Sad?) Editable SALV Day!.
You have my sword, and my axe, and my bow (and my like).
...and my sarcasm. 🙂
Happy anniversary, y'all!
The users love editable ALV because it's so much like Excel. Few years ago there were some sales reps from MS Dynamics trying to pitch it as a replacement for SAP to my employer at the time. The users almost signed up when they saw how well integrated with Excel it was. True story.
Here here, Paul. I hit this issue last week with a multi-level ALV. The new class doesn't seem to support push buttons in each row. I had pitched Fiori Elements but the customer wanted a GUI transaction. The new classes aren't finished.
…well, I think there is nothing to add… ?
Brilliant, I laughed out loud whilst reading this! and whilst it is comedy gold, there is also a serious point here - GIVE US EDITABLE SALV!
I work for a large multinational and probably the number one requirement that is always asked for is "can I have that like in Excel."
and that inevitably means editable!.
Nothing to add. We need and want it!
Michelle
FYA - the link is wrong 🙂 it points to the 2016 Celebration
https://blogs.sap.com/2017/02/08/international-editable-salv-day-2017/
https://blogs.sap.com/2016/02/08/international-editable-salv-day-2016/
"nil bastardum carborundum"
I have tried several times now to use the "insert link" feature to paste in the correct hyperlink.
Now instead of a hyperlink that appears to point to one place but actually points to another I have the correct hyperlink which does not do anything when you click on it.
This whilst constantly being logged out. The SAP Community website is not having a good day today.
Let us see if I can insert the link into this comment.
https://blogs.sap.com/2017/02/08/international-editable-salv-day-2017/
Really surprised that you used prefixes in your book ABAP to the future 😀
Cheers 🙂
If you read the comments on that NOMEN blog all about naming conventions you will see they go on for about ten years. At the start I was in favour of CONSISTENT naming of variables rather than every single company doing their own thing.
During that ten year period myself and some others were converted,and realized the most important thing is code that read like plain English. Thus, in the first version of my book the prefixes are there, and no inline declarations,in the sedond version every single line of code has been re-written and there are inline declarations all over the place and no more prefixes unless they add value.
Some would say they never add value, as I have said I place more importance on it being obvious what the code does than to any unbreakable rules for and against prefixes.
We'd be lucky to have consistent naming of variables *within* one company... let alone across all of them.
Even though I agree, it's not just about if they add value or not. It's also the fact that can be harmful and misleading as well. I have been misled by "LT" prefixes of tables that were, in fact, global. This caused quite a few minutes of head-scratching, especially if we're doing support on one of those "monster" legacy programs.
I've come across that, misleading prefixes, and indeed comments, and indeed documentation in word documents, all of which refer to something that has now changed, making them big fat lies.
The biggest prize has to go to naming a constant something like C_10, and then changing the value to something other than ten. Then you have a magic number mixed with a lie.
The question is, can you make it obvious inside a method what is local, what is a parameter, and what is a member variable? Some would say it does not matter, as long as it is obvious what is what - which could involve calling a parameter "RESULTING_WIDGET_COUNT" instead of "R_WIDGET_COUNT" which is the same as a prefix really, it just looks more like English,
Agreed, but a different type of prefix. That would be a "functional" prefix (which seems to be acceptable in SAP by most authors).
Whereas "scope" and "technical" prefixes seem to be out of favor these days.
Cheers!
Fun fact.
I was at SAP HQ the other day and it turns out that nowadays the internal rule at SAP is that all new standard SAP code must be written with Hungarian Notation e.g. LS_ for a local structure.
Official SAP UI5 JavaScript code follows a similar convention.
So I think that NOMEN blog did what it was originally aiming to do, but in the interim a lot of non-SAP developers (and Horst Keller) decided that prefixes were not the way to go after all....
I've had really bad times because of the lack of this particular functionality.
Yes we absolutely need it!
@SAP Maybe for this years Christmas gift - Editable SALV? 🙂
I've been following this topic since a couple of months ago when I read all those discussions on SCN about editable SALV and got to know the important people involved in the celebration... 🙂 I gave up on the idea and then persuaded the customer to give them a much better solution that changed the work process as to not use any SALV or ALV table at all. This happened some months ago, and immediately I forgot about all of it and stowed it away in the dusty archives of my developer mind.
Today I got a request to convert some ALV report to SALV to get the nice auto-sums and totals. After I was done copying my years-old SALV demo template I came here and then re-discovered the issue and remembered I would now have to use Naimesh Patel's class or other kind of workaround. As much as I'm amused by the yearly celebration I really don't feel like getting into those solutions, so I'm going to keep my report as ALV and tell my manager that it is just not doable.
Still, I would be very glad to keep celebrating Editable SALV Day for many years to come. Happy anniversary!