Fixed-width columns in a GridView

May 1, 2007 at 12:10 PM
What is the recommended practice for allowing fixed-width columns in a GridView with the adapters enabled? The width property doesn't get applied, and without defining a custom style for each column (thus being applied to each cell), I don't see how I can define these widths.

If the way forward is to enable the width attribute of the gridview (which I know how to do by changing the adapter source code), then it would be good to get some sort of property on the adapter to specify allowable attributes (I don't like having to make my own custom changes to the adapter, then have to reapply them every time someone else fixes a bug!).

Richard
May 1, 2007 at 4:07 PM
Have you tried it by writing a CSS class and referencing it via ItemStyle-CssClass? There are limitations to GridView. I generally write my tables in plain HTML and use repeaters to generate content, giving me the ability to use COLGROUP tags for widths.

Also, if you have a patch/fix, post it here and we'll review and incorporate it into the source code.
May 1, 2007 at 5:02 PM

bdemarzo wrote:
Have you tried it by writing a CSS class and referencing it via ItemStyle-CssClass? There are limitations to GridView. I generally write my tables in plain HTML and use repeaters to generate content, giving me the ability to use COLGROUP tags for widths.


I mentioned above that I saw individual css classes for a cell as one way, but one that I thought was wrong. The main reason that I dislike this (probably more of a problem with HTML) is that this would have to be applied to every cell in a column (on every row). On a large table, this again makes things quite unwieldy. What would be better is if this style were applied using col/colgroup elements - I believe this should be done by the adapter itself. Is there any reason why ItemStyle-CssClass is applied as the class element on every cell rather than by generating a COL attribute? This would make the markup a lot smaller for large tables!

I don't like having to resort to outputting my own table with a repeater - this is what a GridView is for, and I would rather fix the GridView and retain the extra functionality it offers than to generate my own from scratch.
May 1, 2007 at 5:06 PM
As an additional way around this, I'd like to consider the option of automatically generating css markup for certain attributes (this could be configurable). For example, if I've specified the ItemStyle-Width property of a cell, the extender could render a <STYLE> section with an auto-generated class name, then apply this to the relevant col. I know this isn't quite separating style from content, but I think it would make the adapter more usable to people wanting a drop-in replacement for normal gridviews.
May 1, 2007 at 8:34 PM
Sorry if I misunderstood your original post.

As I mentioned, I use COL/COLGROUP extensively in non-GridView implementations. It certainly would be nice if the GridView implemented this as well. At this time, it doesn't. It wouldn't be an easy implementation but would certainly be useful. Hopefully someone will take a crack at it. :)

Another thought: Add a CSS class that sets item width to your headers only. Typically this will force the column to take on that width. From the CSS 2 standards:

  1. A column element with a value other than 'auto' for the 'width' property sets the width for that column.
  2. Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns.
  3. Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing).
May 1, 2007 at 11:38 PM
I can't see that the colgroup implementation would be all that difficult, especially if all it's doing is taking the ItemStyle-CssClass property and applying it to a colgroup instead - it would just be added in before the rendering of the thead section. I may well have a crack at it tomorrow.

Your second suggestion does seem better way of accomplishing the same thing for the moment without any changes. The only limitation is that it is only effective for the width property. Col/Colgroup allows specification of some more properties (e.g. I can set the background colour for a column). However, I started running into browser differences when I started experimenting with CSS on cols, so I don't know how much CSS can be reliably applied to a COL (e.g. IE applies font-weight/size etc, FireFox does not).
May 2, 2007 at 3:21 AM
Col/Colgroup allows specification of some more properties (e.g. I can set the background colour for a column). However, I started running into browser differences when I started experimenting with CSS on cols, so I don't know how much CSS can be reliably applied to a COL (e.g. IE applies font-weight/size etc, FireFox does not).

The issue is that that most properties are not officially supported on COL/COLGROUP. See the CSS2 spec and you'll find that the only official supported features are border, background, width, and visibility. Further, Firefox and IE implement the visibility differently -- Firefox's implementation, though "by the book," is not nearly as useful as IE's. (A while back I tried to adapt TableKit to programmatically hide column groups, but the difference made it almost impossible to do effectively.)
May 2, 2007 at 9:28 AM
Aha - that's the section of the spec I was unsuccessfully looking for last night. I guess what's really needed to solve this is an extra set of propertie supported by the GridView columns (ColStyle-CssClass, ColStyle-Background etc). That way, if people still need to be able to set the font style etc they can still use ItemStyle-*.

But as that's not going to happen, I'm wondering whether there is a valid reason for doing the COL/COLGROUP stuff or not.
May 2, 2007 at 2:38 PM
It's a tough implementation to figure out. There are four "column" styles: background, border, width, and visibility (which should be avoided, in my opinion). Class declarations on a COL/COLGROUP do not pass to columns.

What makes it trickier is how to organize your COLs and COLGROUPs. Ultimately you may need to add functionality to the GridView which can then be picked up by the adapter.

There's a lot of table markup and features that should be implemented. COL, COLGROUP, CAPTION, TH with appropriate SCOPE attributes, support for multiple row headers...
Jul 26, 2007 at 7:37 AM
I would TRULY love to see COLGROUP added into the mix. Currently, I segregate groups of COL tags into seperate COLGROUP tags, then use CSS to show a line between the sections. This is the one thing I really wish I could carry over to this.

Anyone up to the challenge? I don't know where to begin.
Nov 9, 2007 at 4:54 AM
I just threw this together, but thus far (without extensive testing) it seems to have allowed me to once again use the ItemStyle-Width attribute. Based on release 2159, I added the following code after line 193 in the GridViewAdapter.cs file (yes, this is C# code):

if ((field.ItemStyle != null) && (!String.IsNullOrEmpty(field.ItemStyle.Width.ToString())))
{
if (String.IsNullOrEmpty(cell.Width.ToString()))
{
cell.Width = field.ItemStyle.Width;
}
}

It might not be the "final solution", but it sure solved my problem. It seems silly to write additional CSS code when the GridView has a property already for the Width.