G
Guest
Ok...I'm gonna regret this...but here goes....(promise I'm not trolling)
After several years of using the provided ASP.NET data display controls
(DataGrids, Repeaters, and now the GridView amoung others), I cannot deny
that there is an ENORMOUS amount of functionality crammed into these controls
- kudos to MS!!!
However, more and more, I have been encountering situations where I need
EXPLICIT control over the rendered HTML in a grid display scenario (custom
client side JS libraries, app/company wide CSS stylings, etc).
In one example, my datasource is an XmlDocument - so naturally, the
XmlDataSource is to the rescue. However, the XmlDocument is 'incomplete' -
it only contains 'keys' (Guids) that require translating into the appropriate
column / field heading / text (the table columns are dynamically definable in
this app, and this lookup information is cached seperately), and it is NOT in
the 'correct' format for simple binding to work (tag attribute model). Ok,
so we hook into the appropriate OnDataItemBound event and modifiy the
rows/columns directly, adding our own controls as we go (way more involved
for Xml binding). Also, we need to wire up some client-side 'nice' events to
allow row-mouseover highlighting, click to select a row and disply in a
details frame (IFRAME - no postback, please), and possibly adjust some
client-side globals for behavior control, and also be sure that the cells do
NOT wrap - all of which is possible.
Problem is, in the end, I end up with slick page(s), some nice helper
classes and powerful abilities that, well, take up WAAAAY more space than me
just redering my grids 'manually', a la classic ASP. I know this is (and has
been) a heated debate since the beginning, but is this a valid option when
the need arises??? It seems to be discounted quickly amoung many, but if
efficiency is key, why (in these situations) would I want to support 2 - 3
times the code???
Flame suit on, advice appreciated...
mike
After several years of using the provided ASP.NET data display controls
(DataGrids, Repeaters, and now the GridView amoung others), I cannot deny
that there is an ENORMOUS amount of functionality crammed into these controls
- kudos to MS!!!
However, more and more, I have been encountering situations where I need
EXPLICIT control over the rendered HTML in a grid display scenario (custom
client side JS libraries, app/company wide CSS stylings, etc).
In one example, my datasource is an XmlDocument - so naturally, the
XmlDataSource is to the rescue. However, the XmlDocument is 'incomplete' -
it only contains 'keys' (Guids) that require translating into the appropriate
column / field heading / text (the table columns are dynamically definable in
this app, and this lookup information is cached seperately), and it is NOT in
the 'correct' format for simple binding to work (tag attribute model). Ok,
so we hook into the appropriate OnDataItemBound event and modifiy the
rows/columns directly, adding our own controls as we go (way more involved
for Xml binding). Also, we need to wire up some client-side 'nice' events to
allow row-mouseover highlighting, click to select a row and disply in a
details frame (IFRAME - no postback, please), and possibly adjust some
client-side globals for behavior control, and also be sure that the cells do
NOT wrap - all of which is possible.
Problem is, in the end, I end up with slick page(s), some nice helper
classes and powerful abilities that, well, take up WAAAAY more space than me
just redering my grids 'manually', a la classic ASP. I know this is (and has
been) a heated debate since the beginning, but is this a valid option when
the need arises??? It seems to be discounted quickly amoung many, but if
efficiency is key, why (in these situations) would I want to support 2 - 3
times the code???
Flame suit on, advice appreciated...
mike