Vreman, Peter - Acision wrote:
Can a hash for a session be added to store user changes of the webui.
Example is the page, limit and filter settings during in the list. When an operation is done and returned to the list the old settings are reused.
The hash can contain things like:
System_list_page
System_list_limit
System_list_filtername
Distro_list_page
Distro_list_limit
The page of a system list can be in the URL, so that it can be bookmarked and shared... but I like the idea of being able to preserve someone's filter settings until they change it a lot.
Yes, we can definitely use the session variable.
Would some of these be better saved as cookie, though, so that they would exist between logins?
Thinking more on this line. Maybe it is better to create a uiconfig Class
The userconfig Class contains the following settings
- Filters array of Hash Name What MatchType Keys Hash
- WebUIColumns array of Hash Name #distro_list/image_list Limit Page FilterName Columns array of Hash Name=Width (Width of the column)
- Reports array of Hash Name What FilterName Columns array of Hash Name=Width (Width of the column)
Methods:
- add_filter(What,Name,MatchType,Keys,Save)
- delete_filter(What,Name)
- expire_filters #remove unsaved expired filters every hour
- add_report(What,Name,MatchType,Keys)
- save_to_disk
- load_from_disk
This class can be saved globally (=admin account) and optionally also per Cobbler login name.
Comments?
Regards, Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Seems reasonable. Call it "UserConfig" perhaps.
Small tip (especially since you seem to be doing all the work! Thanks!) -- For fields that have an obvious name as a primary key, these should be stored as hashes of hashes, not arrays. This prevents having to loop through them and it's much easier to handle and read
I suppose it would be fine to save them with the object system, though we might want to take some extra steps to avoid them showing up in the command line -- to keep the options down.
I'm not sure we need the idea of expiring or temporary filters... you could just require all of them to be saved before they are used. Keeps things simple.
If you used the existing object system you also wouldn't need to do the save/load_from disk stuff ... it would just work. My main concern with that was really the extra stuff that would have to go into the CLI and manpage, and we can simply keep that from showing up in the CLI since it's web app specific.
Sound good?
--Michael