Code Name: Discovery!

For the first time ever, I’ve decided to name the next upgrade to SpellDamage. The next version of SpellDamage (version 2.5) is code named Discovery. There’s a very significant reason that it’s named that way. In the coming weeks I’ll be releasing some sneak peeks into the new version.

Let me just say that the next release will blow you away! I’m not kidding here folks, the port to the ASP.NET MVC framework is coming along MUCH better than I expected… In fact, halfway through porting the Mage calculator, I stopped… stunned! At a sudden realization that with just a few tweaks, SpellDamage.com could become a serious contender as one of the most useful WoW fansites.

Here’s a little tidbit of what’s in the works right now. Now think big… no, bigger! I’m cutting the Top feature. “Wait, that’s not big!”, you say? Well, your right… it’s what it’s being replaced with that is HUGE! It’s so huge that I’ve named the feature “Discover” (which has such an impact on SpellDamage, that I’ve named the next upgrade “Discovery”!).

I’m going to leave it at that for now, let you try to imagine what Discovery could possible mean for a site like SpellDamage.com. But, for now, go to the spell damage calculator of your choice, play with it, get used to it… but get ready for it to change drastically (ok, not the calculator itself, although that’s in the works too)!

Thanks for reading!

The (Upcoming) Lifecycle of a Calculation

In order to truly port SpellDamage to the ASP.NET MVC framework, I need to adopt some RESTful conventions. It’s not entirely a simple process to port a web forms ASP.NET site to MVC, especially if the whole MVC pattern is unfamiliar. Some of the things that were handled for me in web forms need to be done more manually in MVC. That’s not necessarily a bad thing, it has forced me to mold SpellDamage into a better application.

First I need to ensure my controllers are doing just that, controlling. You could almost think them as conductors, orchestrating the application. They contain actions, which you imagine are the things that happen on the page such as list, create, edit, etc… Controllers aren’t aware of how to retrieve data, and shouldn’t really contain a whole lot of business logic either. They control the flow and rely on models and views for the other tasks (data/business logic and presentation).

Models need handle the brunt of the work. They perform the data retrieval and business logic. They don’t understand the flow of the application, nor how to present anything to the application user. They rely on controllers and view for that.

Views handle the presentation tasks. They aren’t aware of the flow of the application and have no idea how to retrieve data. They rely on controllers and models for that.

In light of that, I need to make a lot of changes, so I went straight for the notepad and pen. What follows are my plans to change the calculation process in SpellDamage forever. In the process, everything will have it’s place and responsibilities in the application… making future changes a cinch (in case you didn’t see it, check out my preview of next years upcoming features!).

I used a digital camera to make these shots, I didn’t have access to a scanner today. The following picture (click to make it bigger) is the first two steps of the new calculation process:

In the pic above (click to enlarge), you can see the initial UI is responsible for gathering the inputs from the user, creating a UIinputs specification and sending it to the SpellFactory. But, before it can get into the SpellFactory, the SecurityGuard does a quick check to make sure it’s ok (don’t pay attention to misspellings in the pic).

After it clears security (see above pic, again click to enlarge) the SpellFactory reads the UIinputs specifications and “creates” the spells based on the specs. (in SpellDamage, the specs are things such as level, class, talents, buffs, etc…). Once the spells have been created, the SpellFactory passes the spells over to the Calculator.

The Calculator takes the spells and performs the calculations, creating a results package (see above pic) which is then delivered to the UI. The UI then opens the package and displays it to the application user. It’s important to note that, at this point, the UI can be anything. It can show the results package in many formats, such as HTML, XML, JSON, etc…

So that’s a quick overview of the upcoming changes behind the scenes of SpellDamage. I hope it was informative, and you can get a better idea of what’s going on.

ASP.NET MVC Framework…

A little while ago, Scott Guthrie introduced the ASP.NET MVC framework, you can read my initial post on the topic here. Well, today I read Scott’s next ASP.NET MVC post, and holy crap the ASP.NET MVC framework looks awesome!

What would the MVC framework do for SpellDamage? I hinted at it in my previous post, but an MVC framework enables some seriously cool features.

First, the native URL routing is simply perfect for my type of application. The URL routing in an MVC framework maps controllers to actions. A template of what a URL would look like in a MVC SpellDamage.com is this, www.spelldamage.com/<class>/<name>/<realm>/<continent>. There would be a controller for the <class> and the other parts would be variables into that controller. The controller would then call on the appropriate view to render the HTML to the visitor.

Second, AJAX! Now, I know… to most AJAX alone means diddly. And, in the world of ASP.NET AJAX it’s generally done wrong simply because the UpdatePanel control is horribly inefficient. But the MVC framework fixes that and allows for smoother calls to ASP.NET AJAX to update only the portions of the page that need to be, severely reducing the amount of traffic to the web server (in turn, increasing performance for the visitor).

Last, but certainly not least, fast, clean, efficient pages. In the MVC model, things like session state, view state, control IDs, etc… are not generated. Only elegant, clean, efficient HTML code is emitted to the browser. In the postback model, there is a ton of extra crap that gets generated into the output to the browser (increasing page size, reducing performance).

In closing, porting SpellDamage to the MVC framework makes perfect sense to me. If MS holds true to their deadline, I should have the MVC framework in my grubby mitts in a few weeks. After that, a quick port to the framework, workout some of the kinks, rework a bit of code, and voila! SpellDamage 2.0 MVC’d!