the idea is to avoid each developer using directly the clientStorage in order to manage the persistence of last-selected values for each and every field; instead, we need an infrastructure that will allow the developer to set something like "persistLastSelectedValue=true" on a dialog field, and the infrastructure will take care of the persisting/reading to/from the clientStorage. 

[BTW, "persistLastSelectedValue" should probably be 'true' by default, as I expect most widgets, especially for selection (i.e. drop-downs, check-boxes, radio-buttons, etc... - not sure about free-text text-boxes though), to want this kind of persistence].

@Vojtech/Alexander: any thoughts with regards to feasibility/scope/effort?

[flagging for rhevm-future for now, until scope will be clarified]

I have one question I don't see the answer to. Do we want this persistence across session (aka using client storage or some kind of storage in the backend) or do we want it persisted only during the session and if you logout/refresh browser the values are reset to default.

I can see an argument for both options, I am just worried we are going to be storing a lot of data in the browser storage.

(In reply to Alexander Wels from comment #2)
> I have one question I don't see the answer to. Do we want this persistence
> across session (aka using client storage or some kind of storage in the
> backend) or do we want it persisted only during the session and if you
> logout/refresh browser the values are reset to default.
> 
> I can see an argument for both options, I am just worried we are going to be
> storing a lot of data in the browser storage.

that's a good question - I tend to think that it would make sense to keep this information across sessions and probably across clients as well... so might be a good idea to actually keep this information per user in a user-preferences profile on the server-side (DB) or something similar. 

any additional thoughts?

@Yaniv/Scott:

- Should persistence be: 

 (1) in-session (i.e. closing and re-opening the browser would clear out persisted values)?

 (2) cross session but per client [i.e. closing/re-opening browser would retain the values, but logging in with the same user from *another* client will bring up/retain a separate set of values]?

 (3) cross session and cross clients (i.e. no matter which session / client - as long as it is the same logged-in user, same set of values is persisted)?

- Should we typically persist free-text fields (e.g. 'Name', 'Description')?

Thanks.

UserExperience keyword added here in order to get advice from UXD team regarding:

- Comment #4

- Design suggestions for a view for displaying/clearing persisted dialog-field values (or maybe user-preferences in general).

I think you summed it up well in comment #4

@Yaniv/Scott - questions for you in comment #4. thanks.

(In reply to Einav Cohen from comment #4)
> @Yaniv/Scott:
> 
> - Should persistence be: 
> 
>  (1) in-session (i.e. closing and re-opening the browser would clear out
> persisted values)?
> 
>  (2) cross session but per client [i.e. closing/re-opening browser would
> retain the values, but logging in with the same user from *another* client
> will bring up/retain a separate set of values]?
> 
>  (3) cross session and cross clients (i.e. no matter which session / client
> - as long as it is the same logged-in user, same set of values is persisted)?
> 
> - Should we typically persist free-text fields (e.g. 'Name', 'Description')?
> 
> Thanks.

Cross session and cross clients will be confusing. I think the best way to go on this is cross session but per client for non text free and non advance items, since this is not a cloning process, be just allowing smart defaults.

(In reply to Yaniv Dary from comment #8)
> 
> Cross session and cross clients will be confusing. I think the best way to
> go on this is cross session but per client for non text free and non advance
> items, since this is not a cloning process, be just allowing smart defaults.

@Alexander/Vojtech: any thoughts on implementation approach?

This can be implemented either on the client side, using the browser-storage [concerns: (1) will we have enough storage space? (2) will be removed upon clearing cookies], or on the server side (concern: would require writing a server-side user-preferences persistence infrastructure, which doesn't exist today). 

Thanks.

If we go the HTML5 storage route, we should have between 2.5M and 10M of storage space depending on the browser (so lets assume the low end at 2.5M). We can store quite a bit of stuff in there. We will have to construct some infrastructure to keep keys and values separate.

There is a new HTML5 api out there for something called indexeddb, which basically allows you to store stuff as if it was a nosql database in the browser. Unfortunately this is a problem with IE as it doesn't support it yet (quick search said partial support in IE10). There is also no official GWT support yet, however there are some projects that wrote wrappers for the functionality, if we decide to go with this we can check out the licenses for those projects. There is also something called webdb which is the deprecated version of indexeddb but it might have a bit more existing support not sure.

To do this we will need at least the following:

1. Pick some storage technology (html5 storage, indexeddb, webdb)
2. Write/get a wrapper to this for GWT.
3. implement some infrastructure to map our fields onto the storage making sure we have unique keys for everything. Maybe form/field combination, or we can use the ID infrastructure if that is implemented for enough fields.

*** Bug 1242856 has been marked as a duplicate of this bug. ***

(In reply to Einav Cohen from comment #9)
> (In reply to Yaniv Dary from comment #8)
> > 
> > Cross session and cross clients will be confusing. I think the best way to
> > go on this is cross session but per client for non text free and non advance
> > items, since this is not a cloning process, be just allowing smart defaults.
> 
> @Alexander/Vojtech: any thoughts on implementation approach?

Given that we're dealing with user's UI preferences, storing them on the browser makes most sense to me.

I don't think that storing such preferences on server side is a good idea.

(In reply to Alexander Wels from comment #10)
> To do this we will need at least the following:
> 
> 1. Pick some storage technology (html5 storage, indexeddb, webdb)
> 2. Write/get a wrapper to this for GWT.
> 3. implement some infrastructure to map our fields onto the storage making
> sure we have unique keys for everything. Maybe form/field combination, or we
> can use the ID infrastructure if that is implemented for enough fields.

IndexedDB [1] is good for storing significant amounts of structured data, allowing for high-performance searches. Plus, IndexedDB has only partial support on IE10. I don't think that IndexedDB is suitable for dealing with simple things like user's UI preferences.

[1] http://www.w3.org/TR/IndexedDB/

For this, we can safely use Web Storage [2] to persist key/value pairs. We already have GWT UI infra for working with Web Storage [3] that we use to store various UI preferences. As for the storage limit, Web Storage spec says "A mostly arbitrary limit of five megabytes per origin is recommended." but even with 2.5 MB (WebKit) it is still enough.

[2] http://www.w3.org/TR/webstorage/
[3] org.ovirt.engine.ui.common.system.ClientStorage

As for the implementation, each dialog has a "hash name" that can be used as storage key prefix. To me, this RFE seems pretty doable.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Serena - do you see this pattern also on other products?
Do we save the user preferences at that granularity? What clusters they like to select? What storage domains?

we aren't creating any new gwt infrastructure (moving to react), closing