I don't think a different component is needed that supports CRUD and reporting, but instead I think IGs need more support more customization via the declarative interface. 

I also think more documentation should be provided that explains some of the assumptions made about the interface (such as that all the columns are squeezed into the current page width, rather than allowing scrolling).

Stewart, thank you for you comment. But I don't think you're seeing the bigger picture here.

The IG is attempting to do many things… and that's great… and giving us more declarative options is also great.

But we are forgetting the power of simplicity. The more requirements you add to something, the trickier and trickier it becomes.

If we want APEX to remain a tool where people can leverage a “basic” understanding of HTML / JavaScript… the IG just won't cut it for very basic needs. No matter how much you document this thing… it's simply at the level of an expert JS developer.

This is why we need something ‘stupidly simple’… and yes I know that APEX loves to solve all our problems for us… but here a very basic CRUD interface (a <table> of <td> inputs) is all that we really need. Anyone with a tiny amount of knowledge how to modify this with CSS / JS can go a long way towards making tweaks as-needed.

Let's stop trying to solve all the problems in a single component… 

The IG is an airplane but it doesn't have to be a bicycle too… and a lawn mower… lol

So… Tabular Form/Report?

Call what you will lol

The IG would already be easier for most developers if the APIs are easier to use. How often do you see this repeated in sample code found on internet:

var grid = apex.region("gridID").widget().interactiveGrid("getViews", "grid");
var record = grid.getSelectedRecords();
etc.

We already created some easier wrappers around the IG APIs. like:

getCurrentRecordColumnValue: function (gridID, columnName)

getCurrentRecordColumnListValue: function (gridID, columnName , displayOrReturn )

@ino.laurensse

Any chance these are shared somewhere on the web?

Thanks in Advance

@stewart.l.stryker

Our wrappers are not “fool proof”, so they need to be modified for your needs. Just as an example:

getCurrentRecordColumnValue: function (gridID, columnName) {
var grid = apex.region(gridID).widget().interactiveGrid("getViews", "grid");
var record = grid.getSelectedRecords();
if (!apex.jQuery.isEmptyObject(record)) {
value = grid.model.getValue(record[0], columnName);
return value;
}
}

Also, the IG isn't always the right user experience - apex_item fits in much more seemlessly on an APEX page, particularly one not aimed at “power users”.

In my opinion there are 3 paths to improving tabular editing in general. These are ideas that have been discussed internally and I hope we can move forward on them in the future

1. Continue to improve interactive grid. Fix bugs, and I hope we will make more options declarative. It continues to be used for cases where there can be a large result set and end user needs control over lots of features like charts, highlights, saved report settings etc. This includes adding a “spreadsheet mode" option for data entry.
2. Add a new region type that is for ‘simple grid editing’. It uses the grid widget but takes away all the user customization - like interactive grid minus the interactive bit - meaning no saved report settings. In this use case the developer decides what features to turn on rather than starting with an IG and then using JavaScript to turn things off (the developer can decide to give the user control over things by adding their own buttons for example). It would also have the same “spreadsheet mode” because that should be a future feature of the grid widget that is shared with the IG region.
3. A set of ‘dynamic form’ features that replace APEX_ITEM and allow creating various UI patterns including flexible number of rows of form fields that can be dynamically added or removed at run time. (No fly-weight pattern here.) Full control over the type and layout of fields - you could layout fields in a table but you don't have to. Use (just about) any item type. Have any number of these on a page. This could use either the model layer or the Fxx arrays like tabular forms for data interchange with server. This is the path that is hardest to explain but we have been taking steps in this direction at a low level for a while now. An example is new web component items and also apex.item.addAttachHandler because these let you add items to a page without having to make a JavaScript API call (initialization is automatic). Another example is data binding that was added in 22.2 but not yet documented and this I believe can be enhanced in the future as part of dynamic forms (think 2-way binding to a model layer). Of course dynamic forms can be used for other things. Note the definition of ‘dynamic forms’ means different things to different people. I'm using it to mean the kinds of things people currently use APEX_ITEM for.

This idea, as stated, is rather general so it is hard to action specifically, but I think it most closely aligns with #2 above or maybe some aspects of #3.

This is EXACTLY the situation we are in!  A team of Forms developers tasked to convert Forms to Apex. We can handle JS snippets here and there but the complexity of the grid is out of our depth. If we use the grid and have to customize anything there's a risk that it won't be maintainable in the future. A spreadsheet mode sounds like what we need.

It should just be a simple grid without the interactivity. 

The developer should configure what is possible in the grid. 

The end users will only use what was declared at design time without all the complexity that come with the requirement of runtime configuration.

My vote would go to #2 of John Snyders comment.

A simpler implementation of John's option #2, (Region Type: simple grid editing) might be to enable the developer to declaratively disable/enable one or many of the Actions menu options (e.g. Columns, Filter, Format→Control Break), as we can with Flashback. 

A declarative method would be a lot easier that defining the JavaScript Initialization Code needed to disable a lot of individual features.

This is the same feeling I have. I can use IG for the straight forward tasks, but as soon as I require more complex functionality/styling I am getting lost in the complexity of the JavaScript functions. The Model Data Grid layers makes it more complex. Very common in the Java world, but I prefer “what I see what I get”.

I know there are a lot of blogs and examples to see how IG works, but it takes too much time to figure it out. but even then there is no certainty you will get what you want.

So I turn to the classic report or IR and use HTML expressions on the columns to make it editable (apex_item is deprecated sadly enough and there for too risky to use nowadays) and write some JavaScript or use CSS to manipulate the data.

This also takes some time, but is for me better to understand. For instance I wanted to have a checkbox in front of the rows which were limited to maximum number to be clicked taking pagination into account. What ever I tried in IG it didn’t work. With a classic report it is working.

So yes please, provide an easy solution which allows rows to become editable in classic or interactive report.

@john.snyders   

As you can see from user's responses, the “#2 option” you gave above is the closest fit.

However, I see two issues with the “#2 option”… which you may want to address:

a) it will be limited to maintenance costs against the interactive grid widget. I.e. now when you change the widget… you'll have to maintain it for two types of regions.

b) since it's still based on the interactive grid… users won't be able to use “basic” understanding of HTML / JavaScript / CSS to make customizations. For example… imagine I want the cell to turn a certain background color “Yellow” based on its value. The JavaScript for this isn't difficult and you can find hundreds of tutorials online for doing this kind of thing. However… if it's built using the interactive grid widget… then you're locked into “hacking the interactive grid” which as everyone keeps pointing out expects you to be an advanced JavaScript developer… and have the free time to actually learn how to hack the IG. Of course you could say “well in this case we can make the highlighting feature declarative”… but that's defeating the purpose because you can't anticipate all 1,000 potential use-cases and make each one declarative without bloating plugin. We are looking for something very simple here.

One of the beauty's of APEX that makes it virtually immortal (i.e. will never get too old and lose its users)… is that it is a JavaScript/HTML/CSS framework. This just means that as the outside world builds better tools for JS/HTML/CSS… APEX gets a “free” upgrade. All of the stack-overflows… all of the new API's… just serve to enhance the APEX developer experience. However there is a glaring hole where we can't apply any basic JS/HTML/CSS knowledge (or googling) to a simple <table><tr><td><input type="text"></input></td></tr></table> kind of paradaigm.

@john.snyders I would love to have those “_dynamic forms_”. 

In some cases I have given up on using the interactive grid due to its "table" style interface which makes it "awkward" to use on mobile devices.

Imagine you have a list of items in a shopping cart. In addition to adding and removing items, the user can change some of the information of each item (such as quantity, size and color). An interactive grid would be perfect for this type of interaction.
The only problem is... it's almost impossible to create an interface with a beautiful, responsive and easy to use layout.

In the end I opted to use the "Cards" component with a customized template, with an "edit" button on each card which opens a modal page with a "classic" form in which to modify all the properties of the single item.
It works... but it's slower having to open, edit and save one item at a time (and it is not trivial to update the cards on the main page without losing the vertical position on the page).

It would be great if there was a way to define a sort of "custom template" or declare a form (with individual items, buttons and row/column display) to apply to each row of the interactive grid, to create responsive (and also very complex) layouts.

Here's an example.

On the left a "classic" form, on the right an interactive grid with the same data/functionality.

It would be awesome if I could place that classic form layout into the rows of the interactive grid!

@andrea galizzi  your use case makes sense. If cards works for you then it is a good way to go. See https://hardlikesoftware.com/weblog/2022/05/05/exploring-new-apis-in-apex-22-1/ for how you can do “Card editing with optimistic UI updates (no need to refresh the report)” This should solve the slow to open dialog page issue.

IG allows defining a details view that looks like cards. IG cookbook shows an example on page 34 (undocumented API) that shares the model between the grid and detail views and it may be possible to make the detail view editable. I don't have a complete example of this.

I agree that the IG javascript is too complicated - and we have no official “APEX IG Cookbook” to explain how to do what we need. Blog posts can help but they are spread all around and not always what we're looking for. And as IG changes with each release, and blogs use of undocumented APIs, it's unclear which path is safe for long term.

Not against #2 option above, but as APEX_ITEM is documented as legacy, would also really like to see #3 materialize. Was told IG is “the answer” but the difficulty I often have with IG is that only modified rows are processed, and sometimes that isn't adequate.