looking for advice/insight into EditorGridPanel column widths

LabKey Support Forum (Inactive)
looking for advice/insight into EditorGridPanel column widths Ben Bimber  2010-08-30 07:01
Status: Closed
 
I have been trying to improve the behavior of LABKEY.EditorGridPanel. For the EHR we are creating data entry forms. In some sections of a form, we need to support a variable number of entries (ie. a patient was given some number of medication during a visit. the number of distinct records per form will vary). Using something like LABKEY.EditorGridPanel is a descent way to accomplish that.

I've talked about this with at least 1-2 other devs, so I dont think I'm the only person with this problem: EditorGridPanel almost never renders with appropriate column widths. I believe this stems from the fact that it uses the 'scale' property that's returned by the API (which itself is a little questionable at times). EditorGrid sets a fixed with for every column. The problem arises if the total width it sets exceeds the width of your grid. You end up with some columns inappropriately wide and the columns on the right being ~10px wide. In the 1-2 cases where we use this (column width is precisely why we dont), I added a columnModelCustomize handler that manually sets widths.

My first question is: is there something I'm missing about the use of EditorGridPanel? Was it designed to be used in some manner that results in friendlier column widths?

In a perfect world, perhaps the grid would behave a little more like an HTML table - with columns auto-sizing. I've been scouring the Ext forums, but have not yet found an ideal solution to produce that behavior. Below are thoughts I have come up with that might improve the column width behavior:

1. stop trying to set width altogether in EditorGridPanel. this results in equal width columns. equal width is not always what you want, but at least columns stop getting cut off

2. continue to use the scale property, but rather than use that value as the width, find the proportion of available width. ie. if you have 5 columns, each with a scale property of 100, but your total grid with is 400, then each column gets: AvailWidth/TotalRequestedWidth * Scale. This assumes that the API is providing a reasonable estimate for the column width relative to the other columns. We just down-size according to available space.

3. there is an approach used in plugin called autosizecolumns. the plugin itself adds a handler so that when you doubleclick a column, it auto-resizes (like excel). that might be a nice addition to editgridpanel, but does not solve the problem that onRender it has odd column widths.

4. the plugin determines column width by setting the width to 0, finding the scrollWidth property, then setting the width to that. perhaps this logic or something like it could get incorporated into LABKEY.EditorGridPanel? The problem is that this works when the grid has data, but makes less sense when it is empty. it would auto-size based on the header in that case.

5. maybe look into the API such that the scale property it returns makes more sense?

My initial thoughts are something along the lines of combining #2 with #3. Does anyone else have thoughts about how column width should get handled?

Thanks for any help.
 
 
marki responded:  2010-08-31 13:11
I don't have great insight into this. In most use cases for the Ext grid the developer knows what columns are to be placed there and manually sets the width of the columns/grid in code.

There is an xml metadata override for scale in columnInfo; I am not sure whether it would be picked up in your cases.

The translation from scale to display width is min(scale * 6, 200)
 
Ben Bimber responded:  2010-08-31 13:19
thanks mark. i will look into whether a metadata override can be done. if column widths can't be made more automatic, then it seems like the best case scenario would be for the API to return a sensible value for scale, so we dont need to worry about that every time the field shows up in a grid.

it still seems like there must be a better column-width solution out there. i will keep looking and let you know if i figure something out.