Agree with this, some users that want to use APEX instead of Excel, like the idea to work more similar to excel… Maybe use a different library to manage grids.

Userfriendly Editable Grids are very important, both for spreadsheet users, and users migrating from Oracle forms. I Agree that these should be prioritized in APEX, and improved/adjusted with the described features. Going forward, it would be great to also see:

• Generate column attributes based on UI defaults
• Running totals 
• Search by number columns

Any simplification to performing customizations would also be welcomed. For now its quite time consuming to customize the IG to suit customer needs, since the architecture of the grid is complex. Perhaps a more simplified JS API on top of the existing, to enable the most common usecases.

+1

IG was never intended to be exactly like or even similar to Excel. There is a fundamental difference that limits the basic nature of editing. In Excel (or more generally a spreadsheet) the UI control in every cell is exactly the same and so they have full control over the keyboard navigation. In IG the UI control is an arbitrary item including including 3rd party plug-ins so it doesn't have full control over keyboard behavior. Another way of saying this is that spreadsheet cells are homologous; just string/number plus formatting, whereas IG cells have various types. Also note that even spreadsheets like Excel have two editing modes it just works a bit different. None of this is to argue that IG is better than Excel, just that they are different. Maybe we missed the mark but I don't think so. One of the things often requested from tabular forms was the ability to use any item in a cell.

Could IG have an “Excel” mode? I suppose that is possible but also a lot of work. The trade off would be that you couldn't have arbitrary column items. This means no select list or date picker etc. This may also mean a trade off on intrinsic client side validations as well.

This editing detail is just one aspect of this meta request/idea which really needs to be broken down into actionable specifics that can be prioritized.  I have not done and do not have time at the moment to do a full gap analysis of handsontable, aggrid.

For anyone that really likes handsontable, aggrid or any other grid it should be possible to create a plug-in for them. Perhaps there are already plug-ins. I realize a go-write-it-yourself answer is not in the spirit of the ideas app but there are many grids and other related UI components out there and people may have their favorites (it is hard to please everyone) and more importantly there are things that we could potentially do to make it easier to integrate such things as plug-ins. For example the APEX model layer is a great way to leverage a lot of APEX specific plumbing that transfers data to and from the server. It would be nice if the IG DML process were extensible/flexible so it could support other plug-ins so that you don't have to write the saving (DML) part of the X grid plug-in yourself. Then plug-ins could participate in other things like master detail, facets, editing.

If there is something in the model API that keeps it from easily being used from a UI component model binding layer I would like to know and it would be something to look into improving.

As for other specifics 

• “cut and paste” there have been various requests related to this, not yet in the ideas app as far as I know although FR-1840 may be similar. There is room for improvement here but the impl is not trivial; maybe better now that IE is gone.
• “maybe use a different library” does not seem likely for APEX given how we have been burned by other 3rd party libs in the past.
• “Running totals” There was a separate specific request for this and it makes a lot of sense
• “search by number columns” Not sure there is a separate idea request but I think it is something we are already tracking internally
• “… UI defaults” I think there is already a specific idea/request for this and it makes a lot of sense.
• “simplification to performing customizations” If this means make more advanced options declarative then I am all on board. It should be a specific idea and vote it up. I'll vote for it. There is one specific (a little too specific) instance of this in FR-1896. 
• “a more simplified JS API” Yes but declarative is better where possible. Don't expect anything too radical but keep an eye out for improvements as we move away from the jQuery UI style APIs.

My understanding of this request is that it is for “Excel” mode + copy/paste improvements, which is a reasonable request. If it is more than that add specifics or add other specific ideas.

I am flabbergasted by the standard defensive response from you, John. Even if something is a “lot of work for you”, it still deserves a discussion as an idea. Besides, do you know what is constantly a lot of work for my teams and I? - Writing extensive amounts of javascript to augment the functionality and user experience that Interactive Grids provides.

Interactive Grids missed the mark. Countless people have expressed similar feedback, so I am at a loss to understand why you are still defensive about a component with a very poor user (and developer) experience.

And when I log a Feature Request, I do not expect a response such as “write a plugin”.  I realize I could have written a plugin, but I want to stick to core APEX functionality which is very difficult when I have clients saying, “I want a grid, but we can’t possibly deploy something so unintuitive and unfriendly for a SaaS product”.

IG is the most un-APEX-like component ever.  I dread every time someone decides to use it, and they call for help. And they always do because unless it's used for straightforward CRUD operations, you always hit a wall. Sometimes it's a bug, and sometimes it's a deficiency, sometimes it's simple idiosyncrasy. There's always complex JS to make it work. Or an apology to the user for some bug that remains for several versions.

I think we can start by discussing what can be done to improve them and which bugs have overextended their stay.

I think that just adding two features would make apex experience much more excel-compatible. With just two flags this could be resolved easily:

1 - Flag for colum “Enable keyboard navigation”

2 - Flag “Enable copy paste in this column”

This way we would preserve all current IG power and flexibility and allow a very common demmanded feature like is being able to copy data between excel or other table based programs and for having arrow navigation. Those two flags could be just limited for text, date or number fields only.

It is complicated. It's easy to say, hey make Excel out of IG. I would be totally happy to have IG working and looking exactly like IR just as rock solid, “only” with edit capabilities. But I guess we won't never even this see happening.

We would need a management decision here. I don't have all the facts and background knowledge - actually none 😊 - so I can only communicate a gut feeling out of my end user experience. 

This said, I would rather have John, Shakeeb, Tim, others also external consultants working on the new UI components for 2030. Just like Apple worked 5 years on Swift. I think just adapting JET components is a dead end. Relying on any - now popular - framework is also dangerous. I think it's worth to build our own framework for a product which is 20 years old and which is considered to be there for the next 20 years. 

From APEX version to APEX version I have a hard time to find any “new feature” that would make it worth to upgrade. On the contrary the risk of breaking valuable existing apps is getting higher and higher. This also means we have everything we need for comfortable living. Just with iPhone 6S. 

I don't see a mind change. They looking for more developers (instead of management and QA pros) which create more “features” and even more bugs making APEX even more complex and hard to test. With this lousy QA system we have in place right now, I'm afraid APEX will never make it back to the reputation it once had. 

We still don't have email notifications for this app when there are new comments, I asked for that since the beginning. So there is no real discussion, same for the announced Advisory Board, never heard of it since then. Also no communication why and when and why not. PR is still miserable. The management can not handle this product anymore they way it needs to be handled. This is not a 10 people startup anymore. It has become a huge company but the management has still a startup structure and thinking. We would need a professional APEX CEO who has experience in managing fast growing companies. The developers give their best, that's what they did for 20 years now, this never changed. It's not their fault and they are not the right people to talk to for a real change 😉

We would need a complete overhaul of APEX 2030. Use the senior devs to make this happen and use the new ones to keep the old APEX alive.

For most developers, the JS involved is way to complex. How often do you have to code “var grid = …”, "var record = …” etc. for simple tasks? We have created wrappers around this, like “getCurrentRecordColumnValue: function (gridID, columnName)”. IG API's could be way simpler than what they are now.

There are probably only a few developers that can fully understand the Cookbook. And even the Cookbook contains code with “unpublished and therefore unsupported API's” to get things done.

I can live without cut/paste. Technically that can be done with 19.2 design but you have to highlight the value you want to cut. To me this is minor but I can see how a seasoned Excel user would find this annoying.

My users want a grid that shows Totals for the columns and a “Grand Total” row. Doing this is a lot more javascript than it should be IMO.  I managed to get these totals added to my grid but in doing so I had to change my fields to Text which means now I can't use the built in number formatting. My users want both.

It would be awesome if a row or column could be identified as a summary row/column and let us select the “cells” that need to be summed.

 I'm also curious why you can add an Add, Edit, Save button but no “Delete” button from the Attributes.

I feel like the idea and comments have two directions. One solution could be as someone describe add a simple cut/paste , enable keyboard, and in the other hand its we really need a new component. The first time that i see IG and the client see IG they love that , and love the fast way to dev and “Simple” appication.  Some months later we received new requirements, business logic and the "Simple CRUD" was need to moved to add LOVs, Checkboxes, sum, default values, selection, etc etc… in that moment found huge undocument ways to do that or just “bugs”. My favorite is setValue(Col, Numbervalue + ‘ ’ ) .. It take me almost a day to realize I need to concatenate with “” as string to work it  .

IG is something like friends and I, try to avoid or recomend, prefer IR with apex_items or just the basic way report + modal.

Going back to the idea, yes maybe this Idea must be focus on add some useful options to the IG, but APEX team needs to think in a new component.

+1

My 2 pence:

It's such a crazy steep learning curve for APEX developers when it comes to IG programming. So many small teams are desperately looking for “someone to the rescue”. And very often we find ourselves working towards the wrong edge of the 80/20 scale - sometimes even failing. This unpredictability at a central point is getting more and more obvious and critical, notably for decision-makers regarding APEX as a strategic platform.

But it's not a hopeless case. As an emergency solution, please pick up and rework the scattered documentation (and please separate the nerdy parts in favour of more bread-and-butter solutions) to make our day-to-day business easier.

I think one of the problems or a source of misunderstanding from the beginning was the positioning of IG. The actual goal of this component was fuzzy, and in particular a clear delineation of the intended (and reasonable for development) functionalities was missing and is still missing today. Unfortunately.
Spreading the illusion (and the promise derived from it) that one could replace Excel with APEX (unfortunately, this was and is often postulated in such a general way) was and is a cardinal mistake. 
It resembles a reckless walk into a minefield. It is only a question of time ...
The definition as "*simple* -and therefore limited in its possibilities- tabular possibility of data input/editing" probably rather hits the core and does not raise unrealistic expectations.
Simple input/editing of data held in a database: 
That's what I use it for. And you shouldn't underestimate how much that alone is worth in itself. 
And there we are at another point that is often forgotten and therefore needs to be pointed out again and again. We work with a database in the "background", in a multi-user environment and via a web UI.  
One thing is clear: Excel is not a database and APEX is not an Excel(substitute).
It is necessary (and this is our task) to make clear the advantages(!) of a database-based solution compared to Excel solutions. There are countless of them; nobody knows that better than we do.
But you have to explain this to the users (and especially to the decision makers), again and again. 
It has to be made clear to them that data quality, security, single point of truth represent the real added value of the database and thus APEX as GUI.
If we don't manage to create awareness for exactly that, to broaden horizon and perspective for that, we (actually APEX -Team) can tinker with IG and extend it until hell freezes over, and we will always only lose against holy and so beloved Excel.
My 2ct.

I see the APEX team feels misunderstood that the IG is not (or cannot be) a replacement for excel.

However I think where the team misses the mark is trying to come up with a one-stop “fits all situations” solution for CRUD and reporting. It feels a bit like they bit off more than they can chew.

While the interactive grid still has its uses…. extending it on our side requires very savvy JavaScript developers. This is counter to the vision of APEX which is to be a mature development platform that requires very little programming experience.

I work with a team who, let's face it, just won't ever be able to handle the complexity of modifying the interactive grid. This isn't a bad team. Just people who aren't trained web developers. They can handle a little JavaScript here or there, but nothing complex.

Which brings me to my final point. Choosing to use an IG is a “risky” decision because as soon as the client requires additional functionality, you hit some brick walls pretty hard. Sure I can get around (most of them) but most APEX developers can't…. if they have that level of JavaScript skill… they may as well become front end developers! So…. what happens in my team? We all say, “too risky” and build Form-on-a-report, or use the APEX_ITEM API.

At least with the tabular form, which I don't think needs to be “demonized” or called out for its rugged simplicity… it's simply input fields inside of divs. Any basic JavaScript/HTML/CSS knowledge can get you far with the tabular form. This makes it a rather extensible tool.

So what I'm recommending is for the APEX team to build us another component. The interactive grid can continue getting fixes/upgrades… sure. But what we need at-the-end-of-the-day is something very simple. Something like that tabular form… minus its obvious and very fixable drawbacks… like the fact you could only have one tabular form per page.

The feeling I get is the more people criticize the IG, the more the APEX team digs in their heels…. doubles down on the tech…. when really what we need is a ‘simple’ solution that is extendable (simple to modify with JS, HTML, CSS)… and doesn't have to be as complicated as the IG. Don't call it “tabular form 2.0” since people choke on the word “tabular form”… but something in that direction please.

John resist the dark side of excel, the interactive grid should not be a pale copy of excel and that's fine. Will have more option in declaration mode, yes. What seems to me the most difficult for developers is the interaction between the models. This could be better reflected in the API documentation and have a few more events to better control in dynamic actions. Keep up the good work in the grid John, me and my friend Maxime (Ask Max) have made some very interesting features for users.

Michel makes very good points.  Improvement of events and IG documentation of the underlying models, how the IG works, and examples that go well beyond simple examples geared toward APEX developers with intermediate experience would be a huge help in itself.

The act of closing this Idea doesn't mean that the spirit of the idea is lost. I think it's fair to state that IG's are the way they are, and pretty much need to be kept as they are, similar to other components. Sweeping changes like these would cause more upset to those using them as is, let alone having to somehow accomodate any customizations that have been implemented over the years (without breaking them and forcing any re-work). Essentially there is no safe way to implement all of these ideas into improving IG's per se - there are just too many details in this submission to implement into an existing component.

How about a totally new region type. Keep IG's the way they are (with bug fixes) and start with a clean piece of paper.

@keith.porter

For what its worth, I have an ‘idea’ for a simpler plugin
 

https://apexapps.oracle.com/pls/apex/apex_pm/fr/r/FR-2348