Happy recording and ringing :)
I am sure designers are screaming right now, developers doing web design what is happening!?!?!?!?!?!
I often find true designers are focused on achieving the best looking, user experience site possible. Which I fully support.
However, what I notice most with my software developer eye, is I have to code that and while buttons appear in the best looking location this is often not the easiest to code!!!
Now I could use a pencil and some paper, but my drawing skills are rubbish, so I used balsamiq and discussed there an then with the designer about button and navigation position until we were both happy. Export to PDF and we both have instant documentation.
Start with StructureMap gentle quickstart, then read Jeremy Miller's Initializing and Configuring a StructureMap Container and you should be IoC’ing in no time at all.
Thanks very much guys.
Back to the TDD & MVC Adventures landing page
As part of the new architecture Inversion of Control (IoC)/ Dependancy Injection (DI) are certainly going to be used.
Two lists of IoCs; ioc-libraries-compared and Hanselmans. Some documentation discussed the ability of swap in/ swap out different IoCs but really I don’t think is that simple because each IoC uses different syntax for start!!
My comparison is far from definitive or in depth but here it is;
Back to the TDD & MVC Adventures landing page
The first time I started with HTML WYSIWYG I kept receiving the ASP .NET “A potentially dangerous Request.Form value was detected from the client”.
The usual options are setting either a @Page declaration or a web.Config Pages attribute with validateRequest="false".
However, neither of these worked?!?!?! So what is specific to MVC? Thanks to David Hayden for the explanation;
1: [AcceptVerbs(HttpVerbs.Post)]
2: [ValidateInput(false)]
3: public ActionResult Edit(Article article)
Notice the ValidateInput Attribute above and the fact that I turned off validation by passing false to it.
If you look at the source of the ASP.NET MVC Framework you will see that the ValidateInput Attribute is masquerading as an IAuthorizationFilter so that it will be one of the first filters to run when a controller action is run. During the OnAuthorization Method it just quietly sets the controller's ValidateRequest Property to the value you passed to it ( false in this case ). That value of the property controls whether ValidateInput gets called on HttpRequest when the ControllerActionInvoker is invoking the action.
Back to the TDD & MVC Adventures landing page
By default the MVC framework will create Controller actions such as Edit or Create with a FormCollection parameter;
1: public ActionResult Create(FormCollection collection)
The FormCollection inherits from a NameValueCollection and as such it’s items are accessed something like;
1: article.Title = collection["Title"];
2: article.Content = collection["Content"];
So where does “Title” and “Content” come from? These items, using convention, are created to represent the posting form’s HTML values;
1: <label for="Title">Title</label><br />
2: < %=Html.TextBox("Title")% >
This seems great for small forms but what about large forms? And what about when a form value id changes in the HTML then you must remember to change the action code too. Well this is a convention so there are trade offs!!
That said, the MVC team have made life even easier with the Bind attribute, so my action code looks like;
1: public ActionResult Create([Bind] Article article)
Under the hood the FormCollection items are matched to the Article properties and now my action receives a strongly typed Article object. This leaves convention remaining only in the HTML ids matching to the Article object’s property names.
Bind offers a number of properties to help with fine tuning the Model Binding. To highlight a few;
1: public ActionResult Create(
2: [Bind(Prefix = "NewArticle", Exclude = "Id")]
3: Article article)
Prefix sets the HTML control naming prefix used, more common in long forms which might have the same type of data such as business address and home address. To support the “NewArticle” prefix show above the HTML would look like;
1: <label for="Title">Title</label><br />
2: < %=Html.TextBox("NewArticle.Title")% >
Exclude sets the properties which are NOT allowed to be bound. So for actions such as Create, you want to ensure there is no possibility of the client setting the Id.
If you require any of Bind’s additional functionality and are simply writing code like;
1: public ActionResult Create([Bind] Article article)
Convention pops up again and in fact you don’t even have to specify [Bind], so the following code will also result in strongly typed parameter objects;
1: public ActionResult Create(Article article)
Just for clarity; To use strongly typed Model Binders you DO NOT have to have a strongly typed view.
Happy binding :) and back to the TDD & MVC Adventures landing page
I got my Google Wave invite this morning *jump for joy*, as you would expect the first look is superb and now I can’t wait to start playing with the Waves :)
Might have a little way to go before I reach the level of these very impressive Wave use cases.
Happy waving
1: public ActionResult Details(int id)
2: {
3: var article = ArticleRepository.Get(id);
4: ViewData["article"] = article;
5: return View();
6: }
Which is utilised in the View something like;
1: <h2>< %=(ViewData["article"] as Article).Title % ></h2>
1: public ActionResult Details(int id)
2: {
3: var article = ArticleRepository.Get(id);
4: return View(article);
5: }
Which is utilised in the View something like;
1: <h2>< %= Model.Title % ></h2>
Strongly typed views are achieved by adding a @Page Inherits declaration;
1: < %@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<Article>" % >
Happy strong typing :) and back to the TDD & MVC Adventures landing page
Having used UrlRewriter.NET for the last few years, it took a little moment longer to fully switch from rewrite rules to the routing routes. Herewith are my MVC Routing understandings;
This is what you get out of the box;
1: routes.MapRoute(
2: "Default", // The name of this route
3: "{controller}/{action}/{id}", // The url pattern
4: new {controller ="Home", action ="Index", id ="" }
5: );
To clarify terminology the url pattern declarations contains three URL parameters. That is; each {curly braced} item will result in a URL parameter which is stored in the Controllers RouteData.Values System.Web.Routing.RouteValueDictionary.
However, this is where MVC’s convention continues with two convention based URL parameters;
What if you want more control over your URLs? Or your URLs just don’t match perfectly to Controllers and Actions? Lets have a look at the Route below;
1: routes.MapRoute(
2: "Article", // The name of this route
3: "articles/{id}/{title}", // The url pattern
4: new { controller ="Articles", action ="Details" }
5: );
What does the new line do? Well under the hood is instantiating the RouteValueDictionary with keys; “controller” and “action”, which have respective values “Articles” and “Details”.
So what about {title}? This will get added to our RouteValueDictionary which could be used somewhere within one of our action methods. But here is convention working for us again. Below shows the ArticlesController.Details method;
1: public ActionResult Details(string title)
2: { }
Notice the title parameter, which I am sure you guessed it, is passed the value of {title} URL parameter.
Just for clarity in regards to new’ing a RouteValueDictionary but also having URL parameter. Take the Route below which has {action} but also news action;
1: routes.MapRoute(
2: "Article", // The name of this route
3: "articles/{action}/{title}", // The url pattern
4: new { controller ="Articles", action ="Details" }
5: );
The new’ing action=”Details” is the default value, so if the URL Parameter actually has a value it will be that which is stored in the RouteValueDictionary.
Conventions rock :) and back to the TDD & MVC Adventures landing page
While I would love to jump straight into my problem domain design/ documentation I have the steep learning curve of Fluent NHibernate. The out of the box prototype will consist of;
The aim is to focus on Fluent NHibernate but to remain within a simple architected and MVC environment.
Setting up Fluent NHibernate;
Well done Fluent & NHibernate :)
Back to the TDD & MVC Adventures landing page
Posts
