DataGrid..GridV iew...etc...

[MichaelY]

Ok...I'm gonna regret this...but here goes....(promis e 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

[Kevin Spencer]

No flame here, Michael,

I'm not sure what you mean by "way more space" to begin with. Do you mean
code that is compiled? If so, your perception is flawed. I can only imagine
the amount of programming code in the source for the DataGrid control.
However, I can imagine that it's quite large.

As for efficiency, what sort of efficiency are we talking about here?

One of the properties of object-oriented programming is that classes take
awhile to write, but when designed well, can be re-used in many ways
(ploymorphism). That is something you just can't do with ASP.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.

"MichaelY" <Mi******@discu ssions.microsof t.com> wrote in message
news:6E******** *************** ***********@mic rosoft.com...

Ok...I'm gonna regret this...but here goes....(promis e 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

[MichaelY]

Guess I should have clarified...oop s!!

By 'space', I meant additional code to hook into other various binding
events, that (as we all painfully remember) was simply contained in-line in
an RS.MoveNext wheel...not that it is more code per se, just a structure that
doesn't (always) lend it self to microscopic customization of every aspect of
the rendered markup - but it is possible.

As for 'efficiency', that was simply a reference work of maintaining the
(possibly) many files that I now have. For example, the grid ASCX and CS
file, perhaps some helper classes (which by habit I separate into individual
files), etc. Since I (currently) don't write controls (I write apps), I
don't package (.dll) every dontrol I write just so I can use it (moot point),
so these files are now part of my app.

To put this into perspective, it has been years since I've written a
MoveNext wheel to draw dropdown lists - DropDownList is just too easy for
this. However, there is only so much to render with a <select> tag....tables
are much different. Perhaps I don't want my grid table rendered with a <div>
surrounding it (maybe I already provided one)....maybe I don't want it
rendered as a table at all (I want DIV's)...maybe I don't want inline styles
- I have a style sheet for this....maybe I want to ID my cells and rows in a
specific manner, etc. While this is all possible with the controls, by the
time you are done, you've re-written all the rendering portions of the
control anyway. And the scenarios for App. A dont' apply to the Apps B, C,
etc., so I can't reuse the code verbatim anyway.

I will NEVER argue that the tenants of OO far outweigh what was (or is)
possible with cASP - it has saved my butt many times over, and provided me
with solutions to problems that were just out of reach using inline,
procedural code. However, sometimes I get the feeling that the only way I
would be taking full advantage of the abilities of the Data controls is if I
were a stand-along control author, selling generic grid components to the
masses.

Please understand that I am not trying to bash these controls - I've used
them (as I've said) many times over with great success. And I am not just
'stuck' on cASP - I don't think I could go back if I had to. What I am
really after is just a better perspective on the uses of these controls, and
ultimately, more knowledge so I can (hopefully) become a better developer.

Thanks for your time,
Mike

"Kevin Spencer" wrote:

No flame here, Michael,

I'm not sure what you mean by "way more space" to begin with. Do you mean
code that is compiled? If so, your perception is flawed. I can only imagine
the amount of programming code in the source for the DataGrid control.
However, I can imagine that it's quite large.

As for efficiency, what sort of efficiency are we talking about here?

One of the properties of object-oriented programming is that classes take
awhile to write, but when designed well, can be re-used in many ways
(ploymorphism). That is something you just can't do with ASP.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.

"MichaelY" <Mi******@discu ssions.microsof t.com> wrote in message
news:6E******** *************** ***********@mic rosoft.com...

Ok...I'm gonna regret this...but here goes....(promis e 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