I Love Javascript!

There was a bunch of fairly straightforward stuff. I had to figure out how to work master pages and how to place text into it. Then I had to figure out how to link to jQuery (included in the .NET MVC installation). It's stored in the Scripts directory. I wanted to put them in the same directory as the view (Views/Home/js) but, and I can't figure out why, it wouldn't serve from there. For the time being, I created an App/Home directory in the Scripts folder. 

Next, I made a Linq to Sql mapping. I basically did the same procedure I documented below and it worked right away. I made a structural decision based on that cool paper I read and wrote about to put the database access code (the Linq stuff) outside the Models. That is, I decided that the Models are business objects and database access is a Service, which is now a directory in my project.

Being enamored with that dropdown binding article from last week, I decided to try my first abstract type. It worked just like in the article and, while I was at it, caused me to an a Services/Interfaces directory for the interface and type class. 

The I learned about the Json() operator. Then I got my first AJAX data out to the page. This was very fun.

The only downside was that Visual Studio doesn't necessarily build the project when it changes. If I forget, then the changes I saved in the code files are not represented in the .dll file (or whatever it is) and the changes don't show in the browser. I have to figure that there is some way to make it recompile the changed bits.

Next step is to retrieve an entire category with details. In fact, it was easy. This Linq stuff is very nice. I got me an object that works right away but then the nightmare began.

The first big problem was that I had two classes with the same name. That was bad. Then I changed the Linq one to refer to both tables (CategoryDetail.cs) and life was better. But then I ran into the real problem.

The Json() operator couldn't serialize my object. It told me that it was finding a circular reference. I tried everything. Eventually, I hit the right google idea and found a page that explained that the Linq objects are the problem.

The object I was trying to convert to JSON was a Category. It's properties are id, name, and a list of Students. It turns out that the Student object has an id, a name and a Category. Category refers to Student. Student refers back to Category. If ever there was anything that is circular, this is it.

The article explains that I could tell the object to treat the detail list as "internal" and thus, not "public" and so, not part of the serialize process. I did it and the error went away. Unfortunately, there were no students either. Eventually, I wrote a routine that extracts the students into a list which can then be serialized.

Then I remember about the "internal" thingy. I change it to public and it breaks. Of course, it does. It's got a Category object inside and those have Detail objects in them. I wonder how far down it goes. It's weird and sort of stupid.

Fine. It works. I have to figure out a new solution in the future because I definitely want to be able to pass an entire category object containing details out to JSON and then get it back for persistence. Maybe that's why I will love nHibernate more that Linq.

Two things: First, the Linq query stuff is very confusing.

Second, I had trouble making a class constructor. It is not supposed to return a value so I did something like:

public void CategoryDetail() { ... }

and got an error telling me I couldn't have a method the same name as its enclosing entity. ?????

Turns out that the "void" is the moral equivalent of saying, "Yes, this does return a value and it's nothing." The formulation that worked is:

public CategoryDetail() { ... }

No void. So that's it.