12.1d: ListGrid autoPersistViewState Automatic preferences sample

[Blama]

Hi Isomorphic,

I saw the new Automatic preferences sample. Again amazing as builtin feature. I did something similar, which works in a similar way, but is using the DB to persist the changes here.

Would it also be an option that you do this as feature? I assume that you already thought about it, but if not, here is what you'd need IMHO. Some new settings like:

• "viewStateDataSource"
• "viewStateUserId" (for the WHERE clause)
• "viewStateListGridName" (for the WHERE clause), would also save you from the locator complexity you describe in the docs.

I don't know if your access to the browser storage is synchronous, which of course makes opening the ListGrid easier and faster in your case (no roundtrip to get e.g. sorting configuration in order to do a correct fetch). But even if not, this might be an option, as it has some other value.

Also, is there a reason you don't have filterState in the ListGridViewStatePart docs? Can it be persisted as well? For me, this is working like a charm with my DB-persist.

Best regards
Blama

[Isomorphic]

The feature of automatic persistence of view state to a DataSource would be a valid sponsorship, but would work differently from what you have in mind: we would want to design it so that multiple different components that are loaded at the same time load their view state together in a single request and that rendering doesn’t take place until the (asynchronous) request completes.

[Blama]

Hi Isomorphic,

That also sounds good - normally a delay of one round trip with a one-row lookup to an indexed table should not matter. For me, I have my working code for my main ListGrids, but just flipping the switch for all other ListGrids is definitely something I'm going to do in 12.1.

What about the filterState in autoPersistViewState? Is it missing on purpose?

Best regards
Blama

[Isomorphic]

Filter criteria are not part of ListGridViewState so it is correctly not listed here.

[Blama]

Hi Isomorphic,

ah, yes, I'm using FilterEditorSubmitHandler for this in my application.
Can you note storing filterState as part of viewState as an enhancement?

As minor FYI: These docs do not list all available viewState parts.

Best regards
Blama

[CourtIT]

...Can you note storing filterState as part of viewState as an enhancement?...

Ditto on this request to add FilterState to ViewState.

I've got a couple ListGrids w/ ~10 columns, FilterEditor multi-SelectItems, etc. Users requesting that these be saved automatically.

I've just upgraded from v4.1 to v12.0.

I understand it may be difficult for you to forecast a delivery date, but I'm trying assess whether to wait for v12.1 autoPersist (no Filter, I understand), or to start coding w/ explicit ViewState & FilterSubmit Handlers that save preferences to SQL.

Any guidance appreciated, thanks!

[CourtIT]

Ditto on this request to add FilterState to ViewState.

I've got a couple ListGrids w/ ~10 columns, FilterEditor multi-SelectItems, etc. Users requesting that these be saved automatically.

I've just upgraded from v4.1 to v12.0.

I understand it may be difficult for you to forecast a delivery date, but I'm trying assess whether to wait for v12.1 autoPersist (no Filter, I understand), or to start coding w/ explicit ViewState & FilterSubmit Handlers that save preferences to SQL.

Any guidance appreciated, thanks!

Never mind. Now that I've started coding to save/restore ViewState & FilterState, and see how they work, I see no benefit to combining them.

[Blama]

Hi Isomorphic,

I just saw the new 13.1d gridSavedSearchBuiltin sample - very cool stuff!

Best regards
Blama

[Blama]

Anyone finding this thread via search - it's also in 13.0p.

Best regards
Blama