Wrox Programmer Forums
|
BOOK: Beginning ASP.NET 4 : in C# and VB
This is the forum to discuss the Wrox book Beginning ASP.NET 4: in C# and VB by Imar Spaanjaars; ISBN: 9780470502211
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Beginning ASP.NET 4 : in C# and VB section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old December 21st, 2010, 03:24 PM
Registered User
 
Join Date: Dec 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default Chapter 14 - Few Questions

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!
 
Old December 21st, 2010, 04:59 PM
Imar's Avatar
Wrox Author
 
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
Default

Quote:
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.
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

Quote:
2. General: I don't understand how one determines whether to use the EntityDataSource events versus, for example, the ListView events to fire code.
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.

Quote:
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?
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:

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

Code:
int myAge = 39;
(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:

Code:
var myAge = 39;
myAge = "Thirty-nine";
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!
The Following User Says Thank You to Imar For This Useful Post:
ASP.NOT (December 21st, 2010)
 
Old December 21st, 2010, 05:04 PM
Registered User
 
Join Date: Dec 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default Thanks

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"?
 
Old December 21st, 2010, 05:16 PM
Imar's Avatar
Wrox Author
 
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
Default

Quote:
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!
The Following User Says Thank You to Imar For This Useful Post:
ASP.NOT (December 21st, 2010)
 
Old December 21st, 2010, 05:19 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Quote:
But then why don't they just make all variables be "inferred type"?
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!
 
Old December 21st, 2010, 05:19 PM
Registered User
 
Join Date: Dec 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default Thanks again

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





Similar Threads
Thread Thread Starter Forum Replies Last Post
Chapter 1 page 14 kermit1965 BOOK: Professional ASP.NET MVC 2 6 October 12th, 2010 10:10 AM
chapter 14 vthunder70 BOOK: Beginning ASP.NET 2.0 and Databases 2 October 3rd, 2007 02:11 PM
Chapter 14 example pkumar@ech BOOK: Professional Jakarta Struts 0 November 15th, 2006 09:10 AM
Chapter 14 JonG BOOK: Beginning Visual Basic 2005 Databases ISBN: 978-0-7645-8894-5 1 March 21st, 2006 10:04 PM
Chapter 14 Mike Smith BOOK: Professional C#, 2nd and 3rd Editions 2 January 4th, 2004 05:13 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.