Two enhancement ideas for Customize View

LabKey Support Forum (Inactive)
Two enhancement ideas for Customize View Andy Straw  2015-11-23 11:28
Status: Closed
 
Here are two suggestions for enhancements to Customize View. If anyone else thinks something like these features would be useful, please chime in. Otherwise, suggestions for implementing something like them ourselves would be appreciated.

1. I often define a default view (of a dataset, list, assay results, etc.) that selects columns, their order, and may define some customized column labels. I then define different named views that apply different sets of filters and/or sorting to the default view. What's tedious is when I want to change the default view, for example, add/remove a column, re-order columns, add/change a custom label - I would like the named views to "inherit" from the default view so that any changes to the default view automatically show up in the "inherited" views. As it is, I have to edit each of the named views - tedious and error prone. So, if there were a way to define a view as an "extension" of another view (not necessarily the default view), similar to how a subclass extends a base class, that would be great.

2. When customizing the view of a dataset, I often take advantage of the ability to bring in fields from other datasets. Sometimes, there are a set of fields from various clinical datasets that I'd like to add to multiple experiment datasets, for example. I have to do the view customization on each of those experiment datasets - have to get the right fields from the right clinical datasets in the right order. Tedious and error prone. What I'd like to be able to do is to define once something like a "column set" which might be something like fields a, b, and c from dataset X, fields d, and e from dataset Y, etc. Define the set of columns once, and then re-use that set of columns multiple times by adding those columns to multiple other datasets. A nice additional option would be: if the column set gets edited, the views that use it automatically see the changes.

Do either of these make sense? Are either of them feasible to implement?

Thanks for any related feedback or suggestions.

(BTW, I tried to post this on the "General Use" Forum, but didn't seem to have permission to post there.)

Andy Straw
University of Rochester
 
 
Ben Bimber responded:  2015-11-23 11:38
hi andy,

yes, we also definitely nearly always set default views on tables, and I agree that tends to be really important in making a table friendly to users. we do all of the things you mention in terms of hiding unwanted default columns, often joining columns from other tables, etc. if you do this from a custom module, most of what you talk about can be done in .qview.xml files. if you define a set of columns in the default view, any other named view will inherit these columns even if not explicitly set. i do not think views created through the UI work like this, but i dont know for sure and it sounds like they do not based on your post.

also note, by default file-based views cannot be edited through the UI. however, in 15.3 you can choose to set 'canOverride=true' in the XML. this lets your module provide a default behavior, but still lets users choose to override it.

your column set idea is also something we've considered. honestly, i kinda like to rethink how column are selected. it'd be nice to have something simpler than current customize view (and that requires less knowledge of the schema structure) where you could choose to join in these sets of related columns.

-ben