First of all, love the book. Very cool. :) Apologies if my question has been answered in the forum or in the book (I searched both), there's a ton of information to digest in both locations. Now the questions...

1. P.527/748, Exercise 4. I'm really unclear about the "DataKeyNames" aspect of this solution. What exactly is the DataKeyNames attribute? I don't recall any previous explanation.

2. General: I don't understand how one determines whether to use the EntityDataSource events versus, for example, the ListView events to fire code.

3. General: I also don't really understand the difference between "loosely typed" and "type inference". Coming from a Classic ASP background, your definition of "type inference" seems to describe exactly what happens with "loosely typed" variables in VBScript: the system figures out the datatype all by its little self, real smart-like. Exact same thing. No?

Thanks!

Data-bound controls keep track of the primary keys of data objects in ViewState. For example, by assigning something like "Id" to the DataKeyNames property, the GridView control tracks all Ids of the records or objects assigned to it in ViewState, enabling you to do stuff like Selecting, Updating and Deletion of rows. For more info:

DataKeyNames on Google
GridView.DataKeyNames

If often depends on what you need to do. As I showed in the book, some stuff can be done only on the data source (such as accessing a strongly typed item such as a Genre entity), while others are better handled by the data controls. The API documentation for the events on the MSDN site should give you a better idea of their capabilities.

Close, but no cigar. The biggest difference is *when* the type is inferred and whether you can change it afterward ir not. In a strongly typed language (such as C# and VB), type inference takes place at *compile* time. Once the type is inferred, it cannot be changed. This guarantees type-safety which can help write better and more robust applications. Consider this example:

The compiler will infer myAge as an int, as 39 is an integer. This is identical to writing it like this:

(Sidenote: I prefer to not use var for these scenarios. I find that "int myAge" is much easier to read. However, var was introduced for a reason: some types cannot be expressed explicitly (such as anonymous types), in which case var is the only way to define them. When using LINQ, var is often used - and needed - a lot.)

Once a type is inferred, it cannot be changed. E.g. you can't change the inferred type, nor the value assigned to it. That means that the following fails:

This fails, because "Thirty-nine" cannot be cast to an int. Since myAge has been inferred as a strongly typed int, this code fails.

In weakly typed languages, inference takes place at run time. In classic ASP, this works fine:

Dim myAge
myAge = 39
myAge = "Thirty-nine"

In a weakly typed language the type is inferred at run-time by looking at the value assigned to it.

Does this help?

Imar

__________________
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Follow me on Twitter

Author of Beginning ASP.NET 4.5 : in C# and VB, Beginning ASP.NET Web Pages with WebMatrix
and Beginning ASP.NET 4 : in C# and VB.
Did this post help you? Click the button below this post to show your appreciation!

Thanks, I'll have to do some more reading on the first 2 issues. And as for the 3rd one, yeah, that makes sense. But then why don't they just make all variables be "inferred type"?

You could, but it would make your code a lot less readable. What do you think the type of the following is?

var firstLetter = 'S';

If you guessed char: well done; but I guess a lot of of people would have said string. By explicitly defining the type, code becomes much easier to read:

char firstLetter = 'S';

You would also make it harder to define types that look like each other like doubles, floats, ints and other numeric types.

Personally, I like being explicit about my type definitions, and reserve var for situations where it's really necessary,

For a much more detailed discussion on why you should or shouldn't use var:

http://stackoverflow.com/questions/4...r-keyword-in-c
http://richarddingwall.name/2008/06/...-it-all-wrong/
http://stackoverflow.com/questions/2.../209261#209261
http://weblogs.asp.net/gunnarpeipman...good-wine.aspx

Cheers,

Imar

__________________
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Follow me on Twitter

Author of Beginning ASP.NET 4.5 : in C# and VB, Beginning ASP.NET Web Pages with WebMatrix
and Beginning ASP.NET 4 : in C# and VB.
Did this post help you? Click the button below this post to show your appreciation!

Many of us with years of "classical" language experience think that inferred types are, at best, a necessary abomination. To be avoided except when there's no other way.

EDIT: Heh. Imar's fast! And right!

Cool, thanks again for taking the time. I've bookmarked this thread and will be following up on all the links you suggested.