ListGrid Adding

[yavery]

Hi,

I'm trying to find an appropriate approach to have a newly added record appear as the first listGrid row.

My listGrid is configured with a backing ResultSet, uses paging and therefore may have only a partial
subset of the whole data the server has to offer for the currently active criteria. I managed to have newly
added rows bypass current criteria filtering so that newly added rows show up in the list even if they
don't match the current criteria (and that part works). I used DataSource.recordsMatchingFilter() to do so.

What I haven't figured out yet, is how to reliably have the newly added rows show up at the beginning of the list,
instead of sometimes at the bottom, sometimes at the top ...

I found a few forum posts about configuring the listGrid to sort so that the newly added rows would come up first
but I'm afraid this technique doesn't work since I'm using paged/partial client-side data.

What would be the suggested approach to have the newly added rows appear at the beginning of the list following
their inserting (add) ?

Thanks for your suggestions.

[Isomorphic]

In general, if you are inserting a row somewhere in a paged cache and the server wouldn't place the row in the same place (or wouldn't return it at all), you've got this fairly complicated issue of having to map between client row numbers and server row numbers.

We don't currently have an implementation of the required algorithms built into SmartClient. When you see a row pop to the top / end of a grid with a paged cache, that's a result of resultSet.updatePartialCache and, as those docs explain, the placement is temporary and will be lost if any operation is performed which would involve rowNums.

It's unclear whether you are looking for something like a flag for updatePartialCache that forces newly added rows to the top, or whether you need something that would actually persist across operations such as loading more data from the server - please clarify.

[yavery]

A flag for updatePartialCache that forces newly added rows to the top would be great.

I fully understand that any further fetching to my list will potentially remove or re-sequence
the newly added rows, and I'm perfectly OK with that.

I just need a deterministic way to show the user his newly added rows, at least for the time being,
until a further fetch() is issued.

How can I implement such flag ?

Thanks,

[Isomorphic]

You would need to "void the warranty" by overriding ResultSet.addCacheData() (an undocumented method). However, if you're looking for a predictable way to keep the new row in view, that's what the system is already designed to do. Perhaps what you should do instead is just find() the row in the ResultSet and scroll it into view (but then again it should already be there..)

[yavery]

Our specific use case is that this new row gets added to a valuesManager bound to the
same data source onto which the listGrid is also associated with, but the addition of this new
row is not made thru the listGrid.add() method directly ...

I think this is why we need some manual trickery to achieve this. I'll further investigate
the ResultSet.addCacheData() approach.

Thanks,

[Isomorphic]

Any which way the row is added, ResultSet.dataChanged() will fire, which should give you the opportunity to discover it's index via find(). We'd definitely recommend looking closely at this approach.

[yavery]

Your last suggested approach (observing ResultSet.dataChanged) would not allow me to have added rows
positioned at top since I'd get notified after the fact ...

This proposed approach would only allow me to scroll the listGrid so that the newly "added" row would be into view.

[yavery]

Could we envision a new configurable boolean property on listGrid (or ResultSet) "alwaysAddTop"
that could be observed in your default ResultSet.addCacheData() method ? When this property is
set (true), it would override your current logic that adds either at top or bottom based on range, etc.

I tried implementing this myself in overriding ResultSet.addCacheData(). It basically works in debug
only because of _underscoreNamedVariables that get mangled in non-debug code. Also, implementing
this myself could lead to problems down the road when your addCacheData() implementation changes.

We need a way to have rows added in a determinist way to the same location (top or bottom), but not
the current ResultSet.addCacheData() logic which looks at range to determine this location.

Thanks,

[Isomorphic]

No, unfortunately a property like that doesn't make sense, because there is no guarantee that we have cache at row 0.

To clarify, our previous suggestion was: don't try to force records to the top, just scroll to wherever the record ends up. Your stated requirement was a way to bring the record into view, this approach solves that requirement. Although again we are confused by your problem statement, since the whole point of the existing behavior of ResultSet.addCachedData() is to place a newly added record in view..

[yavery]

We have a multi-select copy feature in place that can potentially copy (add) more than one record. The source records for the
copy can be scattered throughout the list (near the top, in the middle, near the end, etc), on different cache "pages". We want
all newly added/copied records to be grouped together following the copy operation ...

We want these newly added/copied rows to bypass filtering and sorting, at least for the time being so that the user can, "at a glance",
confirm his copy operation's output, etc.

We have implemented the copy as an 'add' data source operation which is working fine. Actual implementation is HTTP 'POST' with 1-N
source record key values. Outputs a JSON array of newly added records.

Based on the current logic in ResuletSet.addCacheData(), you favour adding at the end over adding at offset 0 (order in which the IF is
evaluated). Simply inverting this IF to first check if row 0 is cached, would also resolve our problem, but I understand going down
that simplistic approach would most probably break things for others, hence that new attribute to favour adding at offset 0 instead of
the end, whenever possible.

This new property idea doesn't need to be a "hard" rule either. The attribute could be called "PreferAddingAtTop" and in order to be
observed, other constraints could be verified (cache at index 0 is valid, etc).

In our specific case, cache at index 0 would always be valid because you wouldn't be able to initiate a copy operation if you
don't have a source record to copy from ... Initial fetch() would result in retrieving cached rows at offset 0.

Hopefully this gives more details as to the specific use case behind this request ...

Let me know if you have other ideas.

Thanks,

[Isomorphic]

While that's a lot of good detail, it actually didn't answer the primary concern which we keep asking about: the existing behavior is designed to ensure newly added records appear in the viewport, so if your target grid were actually scrolled to the end or middle of the dataset, the existing behavior would do the right thing, and your proposed behavior would place the records out of the viewport.

So this still isn't making much sense as a framework feature - if we added such a flag, what would the docs say? Enable this setting to incorrectly place added records out of view? We certainly can't add a flag like that (let alone class it as a bugfix), so, although you are right to feel queasy about modifying an internal method, at the moment, that remains our recommendation.

[yavery]

Standard behaviour (scroll to newly added records) sometimes works, sometimes doesn't, hence
our stubbornness to have this alternate approach working ...

In my listGrid implementation, following a copy/add operation, I issue a this.body.scrollToTop() as you
suggested doing in a previous forum post:

http://forums.smartclient.com/showthread.php?t=1651

So, a combination of listGrid.scrollToTop() and a ResultSet that inserts newly added/copied rows at
index 0 is the perfect solution for us ...

The problem I have with my current implementation for ResultSet.addCacheData() is the following:

	if (newRows.length == 1)
		this._lastUpdateRow = 0;

In order for the logic to fully work, I need the above line, but because of the _underscore in the _lastUpdateRow
attribute name, this only works when running the application in debug mode.

These attribute names get mangled and setting this property when the code is obfuscated doesn't have any effect.

If you can tell me how to generate the obfuscated name for _lastUpdateRow, I'd be fine, although I'd much much much
prefer a standard framework feature allowing to scrollToTop/addToTop upon adding, using a new boolean property.

Thanks,

[Isomorphic]

Standard behaviour (scroll to newly added records) sometimes works, sometimes doesn't, hence
our stubbornness to have this alternate approach working ...

Our recommendation again was to wait for the dataChanged() event, find one of the newly added rows via find(), then scroll to that row. If you're saying that's not working, all we need is a test case reproducing the problem, and we can fix it.

About renames of internal variables - just look at the obfuscated method (as easy as ResultSet.getInstanceProperty("addCacheData")) and you can see the obfuscated name. The obfuscated name is stable across releases.

[yavery]

Indeed, by removing my custom logic everything works, except that last element of unpredectiveness, which is whether
rows get added at the top or bottom of the list.

We'll give this a shot ... That is having the framework decide whether the rows get added at the top or bottom.

We'll see how users react to that, but other than that, indeed, the proposed approach does work.

Thanks,