Databinder.eval( ) mystification

[Guest]

a general question...
I'm a bit mystified by Databinder.eval(object, Colname, [format])

if controls can be bound to their individual data sources within the load
event of the page...
why would we ever use this quite inelegant OO code wrapped in #<% %> inside
the markup?

secondly:
sometimes you see simliar code inside the markup without calls to
Databinder.eval that everyone says avoid as it uses reflection...what is that
second form?

finally:
is it a question of elegance/inelegance, or are there things that
Databinder.eval() can do that can't be done any other way in code behind.

Thanks in advance and regards,
CharlesA

 

[Karl Seguin [MVP]]

Controls can't be bound to their values in Page_Load during a databound
operation - specifically what Databinder.Eval is meant to do. They can be
set in the ItemDataBound event however.

The 2nd form is to cast the Container.DataItem to the type of the underlying
datasource. So if you are binding to a DataSet, DataTable or DataView, the
underlying row type is DataRowView, which you can use to do:

c#
((System.Data.DataRowView)Container.DataItem)["FirstName"]
vb.net
ctype(Container.DataItem, System.Data.DataRowView)("FirstName")

if you were binding to a collection of "User", you would cast it to "User"

DataBinder.Eval DOES use reflection. It DOES cause a performance hit. BUT,
it's implementation agnostic of how your business layer is implemented.
DataBinder.Eval doesn't care if you are using a rich domain model or table
modules (ie, datasets). It let's you change some of your business layer/data
access layer without needing to also change your presentation layer. In
that, it's absolutely wonderful.

I would recommend that you always use DataBinder.Eval, unless you've done
some specific profiling and found it to be a performance hog in your
scenario. Otherwise it's a micro-optimization which sacrifices some nice
low-coupling.

Karl

 

[Guest]

Thanks Karl!
I got very nearly all of that (thanks especially for reminding me that the
second form just didn't have the databinder.eval and only the
container.dataitem) and I particularly got the casting bit if you use your
own custom objects...

however you wrote (and I didn't really get this):
Controls can't be bound to their values in Page_Load during a databound
operation - specifically what Databinder.Eval is meant to do. They can be
set in the ItemDataBound event however.


and I'm not sure what that paragraph means, could you elaborate a bit more
please?

I know that the itemdatabound event is called after the ItemCreated event
for the DataGridItem, but I thought all controls could have a data source if
they had runat="server"

Thanks again
Regards
CharlesA

 

[Karl Seguin [MVP]]

well, if you have:

<asp:literal id="FirstName" runat="server" />
sure you can go in Page_Load and do:

FirstName.Text = Whatever;

but if that's in a bound control, ala:


<ItemTemplate>
<asp:literal id="FirstName" runat="server" />
</ItemTemplate>
you can't do the same thing in Page_Load

FirstName doesn't exist in the context of the page, only as a child control
of your repeater/datagrid/datalist.

Your only 2 choices is to do:
<asp:literal id="FirstName" runat="server"><%#
DataBinder.Eval(Container...)%></asp:literal>

or hook into the ItemDataBound and do (pseudo code)

if e.Item.itemType = Item orelse e.Item.ITemType = Alternatingitem then
dim firstName as Literal = e.Item.FindControls("FirstName")
firstName.Text = ctype(e.Item.DataItem, DataRowVIew)("FirstName") 'or
you could use DataBinder.Eval in here as well)
end if

between the two solutions, the %# is way simpler, and I'd only go into
ItemDataBound if there was some more complex logic to do.

The point is, you can't do this during Page_Load, because the datasource
isn't applied to the parent control (repeater/datalist/datagrid) during
page_load but rather during databinding..

Karl

 

[Guest]

Karl
you're a top man!
Thanks for that thorough and great explanation, it's cleared a big piece of
confusion for me!

thanks again and warm regards
CharlesA