OK, so I've been going through the online Ruby On Rails Tutorial by Michael Hartl for the last few weeks in my spare time, and I'm a better programmer because of it. I've not taken any shortcuts and have learned quite a lot. The whole Model / View / Controller aspect of it came pretty easy to me since I'm a full-time ASP.NET MVC developer in my day job. Server side tags, module level variables, and helper modules are shared concepts from the ASP.NET MVC world (which I think they stole from RoR, but...). I'm really liking my new hobby.
I've learned quite a few tricks that make Ruby on Rails much more pleasing to work with than ASP.NET MVC. Namely, I like the built-in gem utilities (package manager for Ruby on Rails), I also like the command line utilities for defining database schemas, generating test records, and auto generating oodles of code. There are so many gems that work together to support testing controllers, models, and views on the fly as you code. I always thought of Unit Testing as a good thing, but it always felt like I was forcing myself to learn / practice TDD. I just never quite "got it"; when I would write unit tests I felt good about it, but as new features come into my project it is very easy to just code my projects without writing unit tests for every little thing. With Ruby on Rails, however, it feels very natural and is almost required due to the dynamic nature of the language. RSpec makes creating tests a breeze.
I'm currently hosting a few Ruby on Rails projects on Heroku, and even doing this is brain-dead easy. I literally auto-generated a Rails project from the command line, and then used the Heroku gem to "git push" my code to Heroku. It does the rest and builds my project and deploys it for the world to see.
Just the other night, I bought a domain and plan to run my very own Ruby on Rails project... I won't give away the domain name yet, but know that I'll be making a big deal of it within the next few months. In short, I love Ruby on Rails and everything that goes with it, including Vim (with rails.vim), Git, Autotest (with Growl), Spork, TDD, and everything else). I can now say that I'm a ASP.NET MVC developer by day / Ruby on Rails developer by night.
Fun!!
Random posts about trail running, computing, family-ing, thinking, and whatever else I choose to say.
Showing posts with label asp.net mvc. Show all posts
Showing posts with label asp.net mvc. Show all posts
Wednesday, October 05, 2011
Tuesday, August 17, 2010
Configuring ASP.NET MVC on Window Server 2003 x64 with IIS6
I'm posting this because it could save somebody hours or days of searching. I wish I had written this before I ran into the problem... (?)
At work today, I was trying to install our ASP.NET MVC web application on a Windows Server 2003 box that was running a 64 bit version of IIS 6.0. I had set everything up just as I have for every other test server that we were using, but this particular machine was giving me big fits.
I would map everything up and no matter what I did, I would get 404 Page Not Found errors from IIS. I made sure that my aspnet_isapi.dll was mapped for a wildcard filter, but still nothing. I was able to get the site to work if I added a custom route inside my Global.asax file to use {controller}.aspx/{action}/{id}. However, I wanted an extension-less approach to our pages that didn't use the "aspx hack" (as I so call it).
After looking all over MSDN, on every ASP.NET MVC guru's blog, and scouring StackOverflow, I finally got the tip that I needed deep within a list of random comments from an old haacked blog entry:
As an additional tip, please make sure you pick the correct version of aspnet_isapi.dll when you are running a 64-bit version of Windows/IIS. Sounds obvious but trust me, it'll give you a major headache if you don't.Erik Burger
At the time it didn't make sense to me because there's only one aspnet_isapi.dll... or so I thought. The user was very vague and provided no additional information as to what he meant. However, this comment got to thinking that perhaps there was another aspnet_isapi.dll specific to 64bit web sites. I went searching, and in less than a minute, I found that there was!
For 32bit websites use this in your wildcard mapping:
C:\WINDOWS\microsoft.net\Framework\v2.0.50727\aspnet_isapi.dll
For 64bit websites use this one:
C:\WINDOWS\microsoft.net\Framework64\v2.0.50727\aspnet_isapi.dll
Once I did that, things started working… You're welcome.
Tuesday, July 28, 2009
Serializing Objects to Json in ASP.NET MVC
I've been working like crazy lately, and haven't been doing much blogging at all (reading or writing). I have a slew of blogs that I want to catch up on. I've barely checked my twitter lately, but reading my blog roll has completely fallen to the way side. The good news is that I've been learning a lot of jQuery, ASP.NET MVC, Linq, and overall enterprise application architecture in a very short period of time! This means that I have a brain full of geekiness just dying to get out.
Building this type of application is really a totally new type of programming for me and has really been putting my brain (and whiteboard) through the some long nights. Over the last few weeks I've really been able to see it all come to light. I'm shooting at a moving target (so to say) and there are changes that pop up along the way that change the system at it's core, where I'm forced to change how objects are constructed and so forth. While I could go on and on about the application I'm working on and all of the problems I've been faced with recently, the topic for this post is strictly related to how easy it is to serialize server side objects to the client.
Problem
I needed a way to represent server side memory objects as client side javascript objects. I have a set of div tags that need to be represented on a canvas (another div) and the user needs to be able to interact with them. Most importantly, I didn't want to re-invent the wheel entirely in javascript by creating all new classes and so forth.
Solution
Json.
Example
Let's say I have an object called "Person" that has a few properties and a collection of PhoneNumbers.
Person
class Person
{
public string Name { get; set; }
public int Age { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Zip { get; set; }
public IList PhoneNumber { get; }
public class JsonSerializer : JavaScriptConverter
{
// override SupportedTypes, Serialize(), & Deserialize()
}
}
class PhoneNumber
{
public string Type { get; set; }
public string Number { get; set; }
public class JsonSerializer : JavaScriptConverter
{
// override SupportedTypes, Serialize(), & Deserialize()
}
}
Inside the 'SupportedType' member, simply return a new enumeration of the parent type. For example the SupportedTypes member inside Person.JsonSerializer would look like this:
get { return new[] { typeof( Person ) }; }
Inside the 'Serialize' method, simply cast the obj parameter to your type, and then begin setting each property like so:
var result = new Dictionary();
var person = obj as Person;
if (person == null)
return result;
result["Name"] = person.Name;
result["Age"] = person.Age;
result["Address"] = person.Address;
result["City"] = person.City;
result["State"] = person. State;
result["Zip"] = person.Zip;
result["PhoneNumbers"] = person.PhoneNumbers;
return result;
Inside 'Deserialize' do the same thing, only backwards (not covered here)... In order to take advantage of the Json data, let's initialize a PersonViewModel class. This class will be used by our View pages. Here is a quick example of what this class might look like:
class PersonViewModel
{
public PersonViewModel(Person person)
{
Person = person;
Json = string.Empty;
}
public Person Person { get; private set; }
public string Json { get; set; }
}
This class will be initialized by an Action method on our Controller class. Inside that method is where I initialize the Json property. In order to serialize our data to Json, we need to register our custom JavaScriptConverters with an instance of the JavaScriptSerializer. Let's do that now!
User calls:
http://mywebsite/Person/Edit/123
This will call the 'Edit' action on the PersonController; this will be where all of the things glue together.
public ActionResult Edit(int personID)
{
var person = _repository.GetPerson(personID);
var converters = new List();
converters.Add(new Person.JsonSerializer());
converters.Add(new PhoneNumber.JsonSerializer());
var serializer = new JavaScriptSerializer();
serializer.RegisterConverters(converters);
var viewModel = new PersonViewModel(person);
viewModel.Json = serializer.Serialize(person);
return View(viewModel);
}
Inside the Edit view, we can now simply use a server tag to initialize a variable to be used by the page (in javascript notation). Here is the best part!!
var person = <%= Model.Json %>;
$(document).ready(function(){
alert(person.Name + ' is ' + person.Age + ' years old');
});
Cool huh?
Building this type of application is really a totally new type of programming for me and has really been putting my brain (and whiteboard) through the some long nights. Over the last few weeks I've really been able to see it all come to light. I'm shooting at a moving target (so to say) and there are changes that pop up along the way that change the system at it's core, where I'm forced to change how objects are constructed and so forth. While I could go on and on about the application I'm working on and all of the problems I've been faced with recently, the topic for this post is strictly related to how easy it is to serialize server side objects to the client.
Problem
I needed a way to represent server side memory objects as client side javascript objects. I have a set of div tags that need to be represented on a canvas (another div) and the user needs to be able to interact with them. Most importantly, I didn't want to re-invent the wheel entirely in javascript by creating all new classes and so forth.
Solution
Json.
Example
Let's say I have an object called "Person" that has a few properties and a collection of PhoneNumbers.
Person
- Name
- Address
- City
- State
- Zip
- PhoneNumbers[]
- Type
- Number
class Person
{
public string Name { get; set; }
public int Age { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Zip { get; set; }
public IList PhoneNumber { get; }
public class JsonSerializer : JavaScriptConverter
{
// override SupportedTypes, Serialize(), & Deserialize()
}
}
class PhoneNumber
{
public string Type { get; set; }
public string Number { get; set; }
public class JsonSerializer : JavaScriptConverter
{
// override SupportedTypes, Serialize(), & Deserialize()
}
}
Inside the 'SupportedType' member, simply return a new enumeration of the parent type. For example the SupportedTypes member inside Person.JsonSerializer would look like this:
get { return new[] { typeof( Person ) }; }
Inside the 'Serialize' method, simply cast the obj parameter to your type, and then begin setting each property like so:
var result = new Dictionary
var person = obj as Person;
if (person == null)
return result;
result["Name"] = person.Name;
result["Age"] = person.Age;
result["Address"] = person.Address;
result["City"] = person.City;
result["State"] = person. State;
result["Zip"] = person.Zip;
result["PhoneNumbers"] = person.PhoneNumbers;
return result;
Inside 'Deserialize' do the same thing, only backwards (not covered here)... In order to take advantage of the Json data, let's initialize a PersonViewModel class. This class will be used by our View pages. Here is a quick example of what this class might look like:
class PersonViewModel
{
public PersonViewModel(Person person)
{
Person = person;
Json = string.Empty;
}
public Person Person { get; private set; }
public string Json { get; set; }
}
This class will be initialized by an Action method on our Controller class. Inside that method is where I initialize the Json property. In order to serialize our data to Json, we need to register our custom JavaScriptConverters with an instance of the JavaScriptSerializer. Let's do that now!
User calls:
http://mywebsite/Person/Edit/123
This will call the 'Edit' action on the PersonController; this will be where all of the things glue together.
public ActionResult Edit(int personID)
{
var person = _repository.GetPerson(personID);
var converters = new List
converters.Add(new Person.JsonSerializer());
converters.Add(new PhoneNumber.JsonSerializer());
var serializer = new JavaScriptSerializer();
serializer.RegisterConverters(converters);
var viewModel = new PersonViewModel(person);
viewModel.Json = serializer.Serialize(person);
return View(viewModel);
}
Inside the Edit view, we can now simply use a server tag to initialize a variable to be used by the page (in javascript notation). Here is the best part!!
var person = <%= Model.Json %>;
$(document).ready(function(){
alert(person.Name + ' is ' + person.Age + ' years old');
});
Cool huh?
Subscribe to:
Posts (Atom)