In the process of shaking down nHibernate, I've learned a bunch about mbUnit. The main thing is that it really wants to be driven from it's management partner, Icarus. Test files will run using Visual Studio's built-in testing framework, but, you basically cannot see any output from the test except the pass/fail notation. That makes it very, very difficult to debug. Icarus is a standalone program. You link it to the assembly dll for your testing project and it shows you the list of tests. When you run them, anything that you write to the console (Console.WriteLine();) comes out in the report as do normal sorts of runtime errors. I'm happy to say that it is very good at seeing the inside of the target system that is being tested. nHibernate has been difficult. One of the things I didn't trust was that the tests were able to see all the files and nuances so I verified. Simply adding a reference to the target projectName.dll does wonders.
There is an industry standard data model made by some gigantic multi-year committee. When I learned about it, I got all excited. These people had designed my data structure!! Woo Hoo!
Then I discovered that it's - literally - 600 pages. Fortunately, there is an xsd file. Even better, Microsoft has a utility in its developer kit (a separate download, "Power Toys") called xsd.exe. It converts an xsd file into some sort of data object class definitions. Considering all the [attributes] they stack into this file, it must have some serious .NET mojo. I don't know how to work that yet. But, I grabbed it into my Macintosh, cleaned the gigantic amount of .NET cruft and converted it into an outline program so that I can organize the class definitions.
My thought is to use the outliner format to select the subset of data elements I want to play with and then take it and convert it into javascript class definitions (ah, the wonders of bbedit and regular expressions). The same data definitions for both sides of my AJAX fence. That sounds like a great thing. I'm so excited.
This has been among my most grueling experiences. Since Wednesday, nHibernate has been showing a "Security Exception" error message. I have been fighting it ever since with absolutely no progress. It has been brutal. I read and experimented, read more, tried something else. Did it again. Again. Again. Again. Again. Again. Weds and Thurs, I went home exhausted. I wrote on technical bulletin boards and got some great ideas from colleagues. There technical details are in this thread on the nhusers group on google. It basically started working for no real reason at the end of Friday. I do not know what fixed the problem. I care, but only a tiny, little bit. Working is working.
I have learned about trust levels in IIS7. There are five of them. The lower three will not allow debugging. The upper two give security exceptions to nHibernate unless it gets to late Friday afternoon and then they don't anymore. I also learned about the 'unblock' feature that prevents files loaded off the internet from being used inadvertently. Rather than asking you if you want to allow a web-sourced file to be used when the file is needed, Windows 7 requires you to select each file, right-click to Property and choose unblock. There is no option to cause it to propagate to enclosed files. Very inconvenient. Anyway, I had to do that for each of the nHibernate .dll files.
Things I got about nHibernate that were harder to find than they should have been:
You need to specify the assembly. I don't think there was a <mapping assembly="AssemblyName"/> attribute in the sample configuration file. It can be specified there or as a string parameter on an addAssembly() (or something like that) when the nHibernate session is created. I couldn't get the latter to work myself.
This is common sense, but the data definition object class name has to either be the same as the name of the table (in a database with a name that matches the one in the database login string in .cfg). If the names are different for some reason, you can us a table attribute (<class name="AssemblyName.Services.BaseDataObjects.categorytBase, AssemblyName" table="categoryBase">) in class element in the mapping file (.hbm).
I just went back, hours later, and took a look. It works all the way through to the database. Sweet.
I've spent the last two days trying to get my first bit of nHibernate
to work. I am in "No Persister" hell. I have done everything and can't make it work.
to work. I am in "No Persister" hell. I have done everything and can't make it work.
Please, for the love of all that is holy, help me!!
If you know anything about nHibernate, please visit this page at google groups, where I detail my pain and save my bacon.
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.
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.
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.
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.
(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.
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