Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • CourtIT
    replied
    Originally posted by CourtIT View Post

    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.

    Leave a comment:


  • CourtIT
    replied
    Originally posted by Blama View Post
    ...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!

    Leave a comment:


  • Blama
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Blama
    replied
    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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • 12.1d: ListGrid autoPersistViewState Automatic preferences sample

    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
Working...
X