Chris Risner . Com

Now that we’ve shown how to incorporate MetaWeblog API, we’re able to get data into our blog.  This means that once we actually have a UI around our site, we can actually show off our blog.  So today’s entry is going to create our basic UI.  Important to note is that we’re not going to do anything REALLY fancy.  Meaning that we’re not going to create any awesome templating engine or make it super easy to change the UI through any sort of administration engine.  Hopefully we’ll do this down the road (so you wouldn’t have to mess with CSS if you wanted to change how the site looks or where different elements appear) but that’s beyond the scope of this entry.

The first thing we’re going to do is lay a few ground work pieces.  Specifically, we need to add some folders beneath our Web projects Views folder.  Then we’re going to create our master pages.  Specifically we’re going to need a folder for the Admin section, the Blog section, and our home section.  Then we’ll need both Admin and Site master pages.  As you can see from the screenshot, we also have a Forum folder and Forum master page.  We’re not going to do anything with these for a while yet but eventually we’ll add a forum to the engine.

We aren’t going to do anything to the master pages yet, except add some links to the javascript files we’ll use.  For now, we’re just going to add references to JQuery and JQueryUI.  Now, we could easily grab the latest version of these scripts and plop them into our scripts folder.  However, wouldn’t it be nice if we could just let someone else host these files?  Someone that was capable of hosting tons of data and serving it up quickly and efficiently?  Thankfully, Google is going to help us out here.  After requesting an API key, you can load up several different javascript files without having to worry about it yourself.  Here is what we’ve put in the head section of our master pages:

   1:  <script type="text/javascript" src='https://www.google.com/jsapi?key=<%: 
                  (ViewData["BlogConfig"] as BlogConfig).GoogleApiKey %>'></script>

   2:  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/
                  jquery/1.4.4/jquery.min.js"></script>

   3:  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/
                  jqueryui/1.8.9/jquery-ui.min.js"></script>

Here, we’re loading the primary google javascript API file with an API key we get from the blog config.  Then we’re just loading up the JQuery and JQueryUI libraries.

We’re going to tie all of our Views directly to screen objects (or View Models if you prefer).  We could create our view files, and then our screen objects, but then we’d have to manually change the inherit Page Directive in each page.  We aren’t going to create every single screen object we’ll need right now, but we’ll create the majority of what we’ll need for the public portion of the site.  Just like we did for the Views, we’ll create subfolders in our BusinessLayer’s screens folder for Admin, Blog, and Home.  First and foremost, we’ll create the Screen objects for our Home views.  We’re going to need an About page, a Contact Us page, and a Home page.  We’re also going to have a page to make it easier to upload files, a generic page for displaying messages, and a page to display generic data we store in the database (think of it like the ability to create add an html page to our website where the content is stored in the database.  So if someone went to ViewContent/Page1, they’d get whatever html we stored in the database for Page1).  For now we’re just going to create Screen objects for all of those and make them inherit from our screen base.  All of these screen objects will descend from the ScreenBase abstract class we added earlier.  For now, we’ll add the methods and properties we’re required to implement from ScreenBase (IsValid and LoadScreen).  We won’t implement these until we’re actually ready to.  We’ve got a lot of other screen objects to create but for now, we’ll jump over to views.

To start, we’ll just create our Home views.  So beneath the Home folder, let’s add the Index view.  When you go to add a new View, you’ll be able to name it (in this case just “Index”) and then we can decide if we want to strongly type the View.  There’s nothing requiring you to strongly type your view to an object.  However, we’re gong to do this directly to our screen objects.  As we’ll see when we get to actually putting stuff on our Views, being strongly typed will make things much easier.  After checking the “strongly-typed view” checkbox, we’ll be able to select our Home.IndexScreen.  After picking our data class, we can select what type of View Content the page will be (Create, Delete, Details, Edit, Empty, List).  If we were binding to an actual Model we might choose something other than Empty, which is what we’ll choose now.  Since we haven’t put anything interesting into any of our Screen objects, choosing something else wouldn’t really help us much.  What get’s created is a very basic view.  All it has is the Page directive line and a little html.  One thing we’re going to have to immediately change is the Inherit’s line in the Page directives.  Right now it’s descending from a System.Web.Mvc.ViewPage. 

Inherits="System.Web.Mvc.ViewPage<Veritas.BusinessLayer.Screens.Home.IndexScreen>"

This is fine for normal sites.  However, we created a VeritasViewPage we want all of our pages to descend to.  So this will now become:

Inherits="Veritas.UI.Web.Views.VeritasViewPage<Veritas.BusinessLayer.Screens.Home.IndexScreen>"

dfdsJust like in the Master pages, this will just give us access to our VeritasForm class in our View. 

Next we’ll create a HomeController class in our Controllers folder.  This will inherit from a ControllerBase class.  The ControllerBase in turn, will inherit from the MVC controller class and will give all of our controllers access to things like our data repository, our BlogConfig, MenuItems, Authentication and Login data in addition to handling unknown actions.  To our HomeController we’ll just add some base ActionResult methods to load our views:

   1:  public ActionResult About(){

   2:      return View();

   3:  }

   4:          

   5:  public ActionResult Contact()

   6:  {

   7:      return View();

   8:  }

Now we’re able to load our views. Well, we’re kind of ready.  If you were to run exactly what we’ve got right now, you’d run into a few issues.  Some of them make sense and others seems like they shouldn’t be issues.  First and foremost, in order for our Master pages to understand what the BlogConfig class is without using the full namespace (how we’re using in the first javascript reference above), we need to import the namespace into the view.  This can be thought of as being similar to a using statement in the cs file.  We need to reference the Models namespace like so:

<%@ Import Namespace="Veritas.DataLayer.Models" %>

Now instead of saying Veritas.DataLayer.Models.BlogConfig, we can just use BlogConfig.  Next we’re going to run into a problem with referencing an “Entity” in the Web project.  The exception you’ll get will be this:

error CS0012: The type 'System.Data.Objects.DataClasses.EntityObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

So, we’ll add the reference for System.Data.Entity to our web project.  However, we’ll still get this error after adding the reference.  The assembly needs to be added into the assemblies node in our web.config like so:

<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

This will fix the problem.  Now things will load correctly and we’ll get to our Index page.  However, if you were to watch the BlogLog table or put a breakpoint in the Application_Error() in the Global.asax.cs, you’d see we’re getting 404 errors.  What could be causing this?  We’re not loading anything in our index view or our Master page.  However, if we look closer at the error, we realize that something is automatically requesting something from our site: the Favicon.  If you read here, you’ll see that browsers don’t need any html to automatically request and load a site’s favicon.  So even though we’re returning a 404 right now, we don’t need to actually fix the problem for the site to work.  We’ll go ahead and add one now.  We’ve got a lot of work left for the UI, but for now, we’ve made a lot of progress so we’ll leave it off here.  You can check out the latest code here.

The team I’m on at work recently took over maintenance on a number of older projects, some of which were never upgraded out of Visual Studio 2005.  The first thing I did for one of them was convert the solution to VS2008.  Unfortunately we didn’t have the time or the resources to do a full integration test and make sure the upgrade didn’t break any existing functionality.  So while my conversion would insure we’d at least be using a relatively recent version of Visual Studio (upgrading all the way to 2010 wasn’t really an option at the moment) we couldn’t do it.  That’s fine as we were going to be rewriting the whole thing sooner or later. 

Yesterday I finally started doing some work in VS2005.  As painful as it was, most of the issues were things I couldn’t really complain too much about.  It wasn’t like I expected Microsoft to update VS2005 so it would run faster.  After making mostly text changes, I ran into something that actually required me to run the debugger.  I loaded it up and started testing my changes, however, none of my breakpoints were being hit.  I looked at VS2005 and the debug toolbar wasn’t there.  I restarted the debugger and noticed that the debug toolbar was disappearing right after the site started (though oddly IE was staying open).  After googling a good amount, I came across this article which explains that IE8 breaks the debugger in VS 2005.  According to the article, IE8 runs under multiple processes and VS2005 doesn’t know how to deal with this.  The easiest solution, and the first offered, is to close down IE before you start the debugger.  If you do that, then it will be able to figure out what it needs to attach to.  Another easy solution (not mentioned in the article) if you don’t want to have to close IE every time you want to debug is to manually attach the debugger to the instance of WebDev.WebServer.Exe that is running your site.

While I rarely ever fire up VS2005, I’m sure there are some shops out there that are still using it pretty heavily.  This seems like something that should have been patched by now or at least a little bit easier to find the solution to online.  Since Microsoft pushes IE8 via the Windows Updates as a required update, it would seem to me that they would also add a fix for Visual Studio.