Wednesday, October 12, 2011

Below is the work-around for problem on non-working ASP.NET UpdateProgress(with AssociatedUpdatePanelID) when the control(e.g. Button) that causes the post-back is outside of the UpdatePanel. This is the cause of the error:

This sort of leaky abstraction on ASP.NET of simulating states in an otherwise stateless protocol is making me embrace MVC+jQuery combo even more.

And someday, you won't get any answer on this type of question on forums, as it will be deemed too localized a few years from now. Five years or more, give or take, most developers will be using MVC+jQuery or node.js+jQuery already, and you will hardly find someone able to answer this ASP.NET type of question.

Given the code above, even if x.Manager is null (or just look like one) the code x.Manager.LastName is not an absurd one. x.Manager == null has no bearing on C# nullability. As far as an ORM is concerned, x.Manager == null needed be translated to its equivalent relational syntax, i.e. that code needed be translated to table2.EmployeeId IS NULL. An ORM is able to do that, as the ORM's mappings contains info on what columns connect one table to another table. The x.Manager.LastName in Linq's select clause is also being translated by Linq Expression provider(e.g. ORM), that's why there won't be any null runtime error on x.Manager.LastName when the LastName is being accessed.

..is now a C#'s null. This code will have a null runtime exception on y.Manager.LastName then.

Perhaps to make code analysis a lot simpler, any code that is still in scope of Linq's Expression should be thought of not as a C#'s construct, and as such, are still subject for translation to whatever SQL syntax it needed be translated, C#'s language rules doesn't come into play when an Expression is still in scope. Linq Expression provider could even translate y.Manager == null to any kind of code; much like C++/C# operator overloading, a plus operator could mean minus, a minus could mean plus. And as far as Linq Expression provider is concerned, the code select new { y.FirstName, y.LastName, y.Manager, ManagerName = y.Manager.LastName } could be translated up to the Linq provider's liking and such can be translated to any kind of code, y.Lastname could be automatically translated to an expression that automatically lowercases, e.g. SELECT Lastname = LCASE(LastName), to even a random one :-)

C# rules could only take effect when things are materialized to objects already, e.g. when using AsEnumerable, ToArray, ToList.

This is the ideal Linq code for properties(e.g. FullName from concatenation in C#) in classes that are not present in database: