mbUnit is on the Air!!

On my way into trouble for this iteration, I created a new project in Visual Studio intended to be the beginning of the real deal. During it's setup, it asked me what testing framework I wanted to use and offered me mbUnit. I chose it and went to work. I created my first bit of nHibernate (ouch!) and made a test to try it out. It failed and sucked up another horrifying amount of time and pain.

I found a small tutorial that just did a tautological unit test (assert a=a). One step explained that I should see the test in Test View. Nope. Nada. Another painful experience trying to make it work. Gave up. Wrote an inquiry to the mbUnit group on google. A nice guy got back pretty quick. He pointed me to a page that looked promising but was long. Since I was in the middle of something else (nHibernate, my new bete noir!), I tabled it for later on.

In my thrashing for nHibernate I, for obscure reasons, decided to make a new project for some reason. While doing it, I noticed that VS offered me, in addition to .NET MVC, an "mbUnit Project." OMG!! I said, Yes, and created one. It didn't look like anything special, so I continued on my Via Dolorosa until I ran out of steam there.

Hoping to salvage something from the day, I looked again at my mbUnit project. I wondered how it was going to know what I wanted to test since it's in an entirely different project from the test target. Let me digress briefly...

During this week's angst, I have come to understand much more about how .NET stuff works. I now know, among other things, where .dll files come from and what they do. They come from a Visual Studio build. I suspect that it is a combination compilation and link process. There is a directory called "bin" that, after I build, gets a filed like, ProjectName.dll. Get a load of that. To get nHibernate and mbUnit going, I had to add a "reference" to their .dll files. Very interesting.

Along the way, I found an explanation about nHibernate that suggested a better file organization (should have done it first but whatever I was learning from at the time got me distracted), ie, a directory specifically for third party software. This seemed like a good enough idea that I paused in my efforts to move things around. That caused me to open the bin directory are really focus. In it, I had put several files for mbU and nH, but lo and behold, there was also, ProjectName.dll. It had also copied the referenced .dll files there as well. Lights went on.

Later, the nHibernate fiasco told me that I needed to have its XML file as an "embedded resource". I did that (to no avail) and realized that must mean that it can pack things into the .dll, as well as put them nearby as references. It also told me that I needed to build explicitly because VS wouldn't automatically detect changes to XML as it (sometimes) does to code.

Cool beans. I am now a reference expert.

Asking myself how mbUnit would know about my real ProjectName, I did two things: 1) added a reference to the ProjectName.dll, even though it was in some other project's directory, and 2) put a using statement that referred to the test target's namespace (using ProjectName.Models) and then instantiated a "TestTarget xxx=new TestTarget();" It had a method that was there for just this purpose and Voila!, I was able to test and will be able to test from now on.

This is killer.

Stuck.

Sending data from JMVC back to C# is a trivial exercise. I have, fortunately, been handicapped with sufficient approval that I feel like I am no longer experimenting. That means that I am less inclined to do things that are mere scaffolding as I have been doing so far. I was thrilled to merely be able to receive a data structure and then display it before. Now I want the next step to be one that contributes more fully to the development cycle.

My plan had been to make JMVC present an input box, collect the data and send it back to the database. I called it, "completing the loop." As I worked into that, I realized that I would need to implement a number of structures to do that and, vis paragraph one here, I felt like I would be wasting time to do that as a mere demonstration. After a day of huffing and puffing, I decided that I needed to decided if the target database was fronted by nHibernate. I also felt like the process of figuring that out would answer a lot of questions.

Then I found a great nHibernate tutorial. It's fourteen video lessons and, if the first is typical, it is an incredibly valuable contribution to the world. Not only did the guy give me view of nH, but also I got to witness someone actually using Visual Studio, see his code and hear how .NET types think about things. I finally understand .dll, for example, and how resources are connected and many other things.

Among those is a more practical understanding of unit testing. Instead of making a display page to show us that his demo worked, he fired up a unit test. This is a huge Eureka! moment for me. I've tried to understand Test Driven Design for a long time, but, having not really seen much in the way of unit testing, I couldn't quite understand how it works. Now I have a clue.

I also saw that this guy, for whom I am developing an intense, loving Stockholm Syndrome, uses mbUnit for his unit testing and made it look easy. I investigated. Most people think that Visual Studio's new, built-in, unit testing will, in the future, be a fully competent framework. A lot think that, even when that happens, the reliance on a single development team at Microsoft will prevent it from being as rich a tool as the other leading one, mbUnit. Since both my colleagues and I are all about open source, that die is cast.

I downloaded mbUnit and installed it. That was the last happy moment of my day.

I haven't yet been able to figure out how to get either VS unit testing or mbUnit to see my code. I spent hours flogging myself about it. I'd give it up but really think that it is going to be the best way to make it so that database server development can be truly separated from control/view development. I have always been confident that unit testing is a crucial technology. Now I think it will make my life easier and quicker. If only I could make it work.

It Gets Difficult

Going from LAMP to .NET is not the only big challenge here. No, I am on the big rollercoaster. Everything I've ever known is out the window. Everything I see is new. It is the most amazing thing. One thing is the use of frameworks. I've never, ever really done it before. Big change in mindset to open my head to other people's ideas with the knowledge that I am stuck with them for the foreseeable future. All this MVC? Probably not the biggest change, but still, I've taken it on at a level that I never considered before. ORM is going to kick my ass. I'm getting ready to be serious about it, but each time I dig, I find the layers of complication exploding and shrink from the immensity. I don't know if it's the right thing to do but I do know. It is. But I'm not sure because it looks so hard.

But this all adds up to a whole new consideration of architecture because, this time, I'm not making a website, I'm writing an application. There are a lot of increased responsibilities with that. Domain driven design. Test driven design. Unit testing. We haven't even talked about actually accomplishing the business needs.

We did a technical review of the project yesterday. I'm happy to say that it went well. I spent three hours telling the boss and the rest of the team why I have been doing all the things I've recorded in this blog. Some are not really web types and so I got to review my understanding of MVC. I talked about the alternatives I've rejected. Discussed the organization of my code, it's structures and my plan to move it forward. The rest of the folks were nice about it and I got a green light to move forward with this architecture.

I'm still really in R&D mode. If you look below, you'll see that I've basically implemented a category/detail demo. It uses .NET MVC to operate the database and JavascriptMVC for the user interface and control. This is strictly a business app and does not have to work for the random public. That means I can write the app in Javascript and use C# as a data service. This is very cool.
At present the app data flows one direction, outbound. My next step is to get some new data and send it back to the server then database. Time to close the loop.

I spent today putting my fingers to the keyboard, sighing. Pausing. Waiting. Getting a cup of coffee. Putting my fingers on the keyboard. Sighing. ... It turns out that there a lot of considerations for this next step. Not only have I been taken away from the safety of still just trying to figure out what to do and placed in the category of, We like it. How long will it take, but I now have to push through territory I already own.

On the outbound journey, I was pioneering. Everything that worked at all was a gift. Simple and barely working was all I want. Now, though, I have a lot of the structures in place and feel like I need to improve everything on the way. That is, it's nice to figure out how to send data back to the database but I don't really want to invest the time without also making progress toward the good solution.

Bottom line on this blab is that I spent all day to realize that my big issue is the one I have always known is the most important single one: data structures. I am stymied because I don't know what sort of objects I am going to pass between C# and Javascript. Objects, obviously. In JSON, of course, but what objects and where are they.

After a while, I started to experiment with the objects I am receiving from the database already. (I had, of course, done so before but really just grabbed the bits I needed to display). It turns out that doing a LINQ query for a set of categories also brings along a set of details, just as one would hope. I can get that and, I suppose, operate on it. That is, as the user enters data, I can store it in that object and eventually send it back to the server. I will have to write a method that plucks it apart and saves the stuff that's changed, make it persist.

Persist!!! That's what nHibernate does. I cycle around my nightmare and try to find a chink in nHibernate's armor. That puts me into despair and, when I'm in despair I procrastinate. In this case, I read a lot about nHibernate and it's handy band of added tools. But, it also caused me to pass through SOA (service oriented architecture) and SOAP. Suddenly I think, maybe I'm resisting the wrong thing. Maybe this should be a SOAP interface. Grab me a WSDL, instantiate a few objects, talk to the database via SOAP.

Is is that making a mountain out of a molehill? My head is going to explode.

Firebug Console Stopped Working and I Fixed It

Somewhere along my way, I lost my ability to use Firebug console, specifically, I could not use console.log(). Worse, I could not examine variables and DOM elements from the console. It would echo the thing I typed but not the result. For example, if I typed "5+5" into the console, the result should look like:

     

While broken, it only showed the ">>> 5+%".

I tracked it down to a jquery statement:

     $('body').html("<div id='container'></div>");

When I changed it to:

     $('body').append("<div id='expressbook'></div>");

It worked correctly.

Someone please explain.

Architecture in a JMVC World

(This is a post I put on the JMVC google group. I include it here in case anyone that reads it has any thoughts and so that I can refer to it myself. If you're smart about this sort of stuff, I'm sure the people at the group would like you to increase their knowledge in the context of the post over there.)

I now have a demo app running and have used many features of JavascriptMVC. I am able to operate the tool in a rudimentary way. Now I am starting to figure out how to do things that I know I will want to do in the future. First among these is global navigation but I am very unsure how JMVC wants me to do it. It occurs to me that this might be something that is interesting to others and I sure could use some advice.

I want to have a set of controls of some sort that, when clicked, each provide a different work context. Think, Page A supports Data Entry, Page B supports Reporting and Analysis. Each wants to have completely separate functions. I think that the basic organization is that I want to have a document controller, call it the AppOvervallController and, then I want to have PageAController, PageBController, etc.

Given this, I would have the global navigation receive a click (though this is mysteriously failing right now) and tell the current page controller to clean up and die, and then tell the newly clicked controller to hop into action. Presumably, that controller would need to have some number of application elements that do things. 

For my demo, Page A has a category list that, when an item is clicked, tells a detail list to fill itself with appropriate details. At present, the category and the detail are each a separate controller.

Really, I'm looking for discussion about whether this is the right way to think. But, I'm also wondering if those category and details are supposed to be in their own controllers? Am I supposed to have a controller for every operating <div> in the app? That also means that I have a separate view folder for each, probably containing only one file. That seems messy to me.

That's enough to ask but, I have one more thing to toss in. On the JMVC website, I see that I can execute a statement like:

TodosController = Controller.extend("todos",{...));

Where "todos" refers to a DOM element named "todos" (id?). Is this how I should be creating my category and detail controllers?

Thanks for any advice.

Today's First Tidbit: IE, jQuery and the Title tag

Firefox will allow you to use jQuery to assign a value to the <title> of a page. IE will not. It gives you an error deep in jQuery: 

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Timestamp: Fri, 26 Feb 2010 17:08:14 UTC

Message: Unexpected call to method or property access.
Line: 260
Char: 5
Code: 0

Fortunately, document.title='Cool New Title'; works on both and with javascsriptMVC.

FYI

Separation of Concerns - ChaChing!!

I made JavascriptMVC work. My demo app is now structured into three controllers: document, category and detail. It has two views, one for the category and one for the details.

The document controller generates html containers for the other two and associates their controllers with their <div>s. I am, so far, treating each segment of the browser window as a separate page. That feels pretty close to right to me.

The category controller has a built-in init function that runs an ajax call to the C# Model to collect it's clickable listing.

When a click is made on a category, it publishes a Get.The.Details event and updates the user interface. The detail controller senses that (I love that JMVC has made that completely invisible to me) and issues another ajax call to get the details.

I think I am going to love this. It is so wonderful to have places to put code in Javascript. I think of all the time I have spent scrolling up and down .js files looking for where I set the X or the Y thingy.

The only thing that's been really difficult so far is Scope. I did find "this.view()" in the video as Justin suggested, but it turns out that callbacks often don't have a good Scope and, until I learn something new, that's going to be a source of hassle and less generalized code than I want.

Here are two things that solved problems for me:

Getting the DOM element when it wasn't part of the scope: 
target=param.currentTarget;

Getting the current object when it wasn't coming through well:  
this.element.html(html);

Honestly, I don't understand it, but, it appears that Scope is going to be my bete noir for the time being. I suffer from it in C#, too.

Lots to learn but, it's been a good day.

Another milestone

I made JavascriptMVC work. My demo app is now structured into three controllers: document, category and detail. It has two views, one for the category and one for the details.

The document controller generates html containers for the other two and associates their controllers with their <div>s. I am, so far, treating each segment of the browser window as a separate page. That feels pretty close to right to me.

The category controller has a built in init function that runs an ajax call to the C# Model to collect it's clickable listing.

When a click is made on a category, it publishes a Get.The.Details event and updates the user interface. The detail controller senses that (I love that JMVC has made that completely invisible to me) and issues another ajax call to get the details.

I think I am going to love this. It is so lovely to have places to put stuff in Javascript. I think of all the time I have spent scrolling up and down .js files looking for where I set the X or the Y thingy.

The only thing that's been really difficult so far is Scope. I did find "this.view()" in the video as Justin suggested, but it turns out that callbacks often don't have a good Scope and, until I learn something new, that's going to be a source of hassle and less general code than I want.

Here are two things that solved problems for me:

Getting the DOM element when it wasn't part of the scope: target=param.currentTarget;

Getting the current object when it wasn't coming through well: 
 this.element.html(html);

Honestly, I don't understand it, but, it appears that Scope is going to be my bete noir for the time being. I suffer from it in C#, too.

Lots to learn but, it's been a good day.

JavascriptMVC Looks Pretty Good

Note the change in spelling. It's not "Javascript MVC". I've excised the space. It turns out that 1) google is much friendlier to inquiries about "JavascriptMVC" and 2) the man behind the framework, Justin Meyer, thinks that's the correct spelling. If his code is good enough for  me, then so is his spelling. Plus he reached out personally, so I am now a loyal friend.

Anyway, this looks like it's going to work. I got it installed in Visual Studio (though I am seriously thinking about moving out of there soon for these Javascript projects). 'Hello World' came up smoothly. It took stepping through the code in Firebug to figure out what folder to put my style sheets in ("stylesheets", not "styles" or "css" or, whatever), but the framework includes them correctly. 

I am having a bit of a hassle trying to get the system to recognize a view. The documentation wiki  has a nice page that purports to explain how to use the view/templating system. I created a simple template and tried to activate it with the code on the page "html= new View..." but it didn't work. I asked on the google group and was told to review the getting started video. I did and, yes, there was a line of code that was different ("this.view('viewName'..."). I'm not sure what the example on the wiki page is about, but what the heck, it is progress.

Next up, mime types. I'm using IIS7 and that means that it won't just serve any old file. In particular, it won't serve the javascript template files with the extension ".ejs".

First, .htaccess == website.config. They are entirely different. .htaccess is an antique format with inscrutable language. website.config is a modern (xml) format with inscrutable language. The cool thing is that you can define mime types in website.config. If that's possible with .htacess, I've not run into it. You can find an explanation and the source of my code sample on a nice IIS website, here.

I added code to tell it to serve .ejs files as text/javascript and it seems to get them. Still doesn't work, but that's why I continue to be alive. To make things work.