Search Results

Search found 5 results on 1 pages for 'fubumvc'.

Page 1/1 | 1 

  • Why is FubuMVC new()ing up my view model in PartialForEach?

    - by Jon M
    I'm getting started with FubuMVC and I have a simple Customer - Order relationship I'm trying to display using nested partials. My domain objects are as follows: public class Customer { private readonly IList<Order> orders = new List<Order>(); public string Name { get; set; } public IEnumerable<Order> Orders { get { return orders; } } public void AddOrder(Order order) { orders.Add(order); } } public class Order { public string Reference { get; set; } } I have the following controller classes: public class CustomersController { public IndexViewModel Index(IndexInputModel inputModel) { var customer1 = new Customer { Name = "John Smith" }; customer1.AddOrder(new Order { Reference = "ABC123" }); return new IndexViewModel { Customers = new[] { customer1 } }; } } public class IndexInputModel { } public class IndexViewModel { public IEnumerable<Customer> Customers { get; set; } } public class IndexView : FubuPage<IndexViewModel> { } public class CustomerPartial : FubuControl<Customer> { } public class OrderPartial : FubuControl<Order> { } IndexView.aspx: (standard html stuff trimmed) <div> <%= this.PartialForEach(x => x.Customers).Using<CustomerPartial>() %> </div> CustomerPartial.ascx: <%@ Control Language="C#" Inherits="FubuDemo.Controllers.Customers.CustomerPartial" %> <div> Customer Name: <%= this.DisplayFor(x => x.Name) %> <br /> Orders: (<%= Model.Orders.Count() %>) <br /> <%= this.PartialForEach(x => x.Orders) %> </div> OrderPartial.ascx: <%@ Control Language="C#" Inherits="FubuDemo.Controllers.Customers.OrderPartial" %> <div> Order <br /> Ref: <%= this.DisplayFor(x => x.Reference) %> </div> When I view Customers/Index, I see the following: Customers Customer Name: John Smith Orders: (1) It seems that in CustomerPartial.ascx, doing Model.Orders.Count() correctly picks up that 1 order exists. However PartialForEach(x = x.Orders) does not, as nothing is rendered for the order. If I set a breakpoint on the Order constructor, I see that it initially gets called by the Index method on CustomersController, but then it gets called by FubuMVC.Core.Models.StandardModelBinder.Bind, so it is getting re-instantiated by FubuMVC and losing the content of the Orders collection. This isn't quite what I'd expect, I would think that PartialForEach would just pass the domain object directly into the partial. Am I missing the point somewhere? What is the 'correct' way to achieve this kind of result in Fubu?

    Read the article

  • How do I create an exception-wrapping fubumvc behaviour?

    - by Jon M
    How can I create a fubumvc behaviour that wraps actions with a particular return type, and if an exception occurs while executing the action, then the behaviour logs the exception and populates some fields on the return object? I have tried the following: public class JsonExceptionHandlingBehaviour : IActionBehavior { private static readonly Logger logger = LogManager.GetCurrentClassLogger(); private readonly IActionBehavior _innerBehavior; private readonly IFubuRequest _request; public JsonExceptionHandlingBehaviour(IActionBehavior innerBehavior, IFubuRequest request) { _innerBehavior = innerBehavior; _request = request; } public void Invoke() { try { _innerBehavior.Invoke(); var response = _request.Get<AjaxResponse>(); response.Success = true; } catch(Exception ex) { logger.ErrorException("Error processing JSON request", ex); var response = _request.Get<AjaxResponse>(); response.Success = false; response.Exception = ex.ToString(); } } public void InvokePartial() { _innerBehavior.InvokePartial(); } } But, although I get the AjaxResponse object from the request, any changes I make don't get sent back to the client. Also, any exceptions thrown by the action don't make it as far as this, the request is terminated before execution gets to the catch block. What am I doing wrong? For completeness, the behaviour is wired up with the following in my WebRegistry: Policies .EnrichCallsWith<JsonExceptionHandlingBehaviour>(action => typeof(AjaxResponse).IsAssignableFrom(action.Method.ReturnType)); And AjaxResponse looks like: public class AjaxResponse { public bool Success { get; set; } public object Data { get; set; } public string Exception { get; set; } }

    Read the article

  • Daily tech links for .net and related technologies - Mar 29-31, 2010

    - by SanjeevAgarwal
    Daily tech links for .net and related technologies - Mar 29-31, 2010 Web Development Querying the Future With Reactive Extensions - Phil Haack Creating an OData API for StackOverflow including XML and JSON in 30 minutes - Scott Hanselman MVC Automatic Menu - Nuri Halperin jqGrid for ASP.NET MVC - TriRand Team Foolproof Provides Contingent Data Annotation Validation for ASP.NET MVC 2 -Nick Riggs Using FubuMVC.UI in asp.net MVC : Getting started - Cannibal Coder Building A Custom ActionResult in MVC...(read more)

    Read the article

  • A Semantic Model For Html: TagBuilder and HtmlTags

    - by Ryan Ohs
    In this post I look into the code smell that is HTML literals and show how we can refactor these pesky strings into a friendlier and more maintainable model.   The Problem When I started writing MVC applications, I quickly realized that I built a lot of my HTML inside HtmlHelpers. As I did this, I ended up moving quite a bit of HTML into string literals inside my helper classes. As I wanted to add more attributes (such as classes) to my tags, I needed to keep adding overloads to my helpers. A good example of this end result is the default html helpers that come with the MVC framework. Too many overloads make me crazy! The problem with all these overloads is that they quickly muck up the API and nobody can remember exactly what order the parameters go in. I've seen many presenters (including members of the ASP.NET MVC team!) stumble before realizing that their view wasn't compiling because they needed one more null parameter in the call to Html.ActionLink(). What if instead of writing Html.ActionLink("Edit", "Edit", null, new { @class = "navigation" }) we could do Html.LinkToAction("Edit").Text("Edit").AddClass("navigation") ? Wouldn't that be much easier to remember and understand?  We can do this if we introduce a semantic model for building our HTML.   What is a Semantic Model? According to Martin Folwer, "a semantic model is an in-memory representation, usually an object model, of the same subject that the domain specific language describes." In our case, the model would be a set of classes that know how to render HTML. By using a semantic model we can free ourselves from dealing with strings and instead output the HTML (typically via ToString()) once we've added all the elements and attributes we desire to the model. There are two primary semantic models available in ASP.NET MVC: MVC 2.0's TagBuilder and FubuMVC's HtmlTags.   TagBuilder TagBuilder is the html builder that is available in ASP.NET MVC 2.0. I'm not a huge fan but it gets the job done -- for simple jobs.  Here's an overview of how to use TagBuilder. See my Tips section below for a few comments on that example. The disadvantage of TagBuilder is that unless you wrap it up with our own classes, you still have to write the actual tag name over and over in your code. eg. new TagBuilder("div") instead of new DivTag(). I also think it's method names are a little too long. Why not have AddClass() instead of AddCssClass() or Text() instead of SetInnerText()? What those methods are doing should be pretty obvious even in the short form. I also don't like that it wants to generate an id attribute from your input instead of letting you set it yourself using external conventions. (See GenerateId() and IdAttributeDotReplacement)). Obviously these come from Microsoft's default approach to MVC but may not be optimal for all programmers.   HtmlTags HtmlTags is in my opinion the much better option for generating html in ASP.NET MVC. It was actually written as a part of FubuMVC but is available as a stand alone library. HtmlTags provides a much cleaner syntax for writing HTML. There are classes for most of the major tags and it's trivial to create additional ones by inheriting from HtmlTag. There are also methods on each tag for the common attributes. For instance, FormTag has an Action() method. The SelectTag class allows you to set the default option or first option independent from adding other options. With TagBuilder there isn't even an abstraction for building selects! The project is open source and always improving. I'll hopefully find time to submit some of my own enhancements soon.   Tips 1) It's best not to have insanely overloaded html helpers. Use fluent builders. 2) In html helpers, return the TagBuilder/tag itself (not a string!) so that you can continue to add attributes outside the helper; see my first sample above. 3) Create a static entry point into your builders. I created a static Tags class that gives me access all the HtmlTag classes I need. This way I don't clutter my code with "new" keywords. eg. Tags.Div returns a new DivTag instance. 4) If you find yourself doing something a lot, create an extension method for it. I created a Nest() extension method that reads much more fluently than the AddChildren() method. It also accepts a params array of tags so I can very easily nest many children.   I hope you have found this post helpful. Join me in my war against HTML literals! I’ll have some more samples of how I use HtmlTags in future posts.

    Read the article

  • Is this a right way to use NHibernate?

    - by Venemo
    I spent the rest of the evening reading StackOverflow questions and also some blog entries and links about the subject. All of them turned out to be very helpful, but I still feel that they don't really answer my question. So, I'm developing a simple web application. I'd like to create a reusable data access layer which I can later reuse in other solutions. 99% of these will be web applications. This seems to be a good excuse for me to learn NHibernate and some of the patterns around it. My goals are the following: I don't want the business logic layer to know ANYTHING about the inner workings of the database, nor NHibernate itself. I want the business logic layer to have the least possible number of assumptions about the data access layer. I want the data access layer as simplistic and easy-to-use as possible. This is going to be a simple project, so I don't want to overcomplicate anything. I want the data access layer to be as non-intrusive as possible. Will all this in mind, I decided to use the popular repository pattern. I read about this subject on this site and on various dev blogs, and I heard some stuff about the unit of work pattern. I also looked around and checked out various implementations. (Including FubuMVC contrib, and SharpArchitecture, and stuff on some blogs.) I found out that most of these operate with the same principle: They create a "unit of work" which is instantiated when a repository is instantiated, they start a transaction, do stuff, and commit, and then start all over again. So, only one ISession per Repository and that's it. Then the client code needs to instantiate a repository, do stuff with it, and then dispose. This usage pattern doesn't meet my need of being as simplistic as possible, so I began thinking about something else. I found out that NHibernate already has something which makes custom "unit of work" implementations unnecessary, and that is the CurrentSessionContext class. If I configure the session context correctly, and do the clean up when necessary, I'm good to go. So, I came up with this: I have a static class called NHibernateHelper. Firstly, it has a static property called CurrentSessionFactory, which upon first call, instantiates a session factory and stores it in a static field. (One ISessionFactory per one AppDomain is good enough.) Then, more importantly, it has a CurrentSession static property, which checks if there is an ISession bound to the current session context, and if not, creates one, and binds it, and it returns with the ISession bound to the current session context. Because it will be used mostly with WebSessionContext (so, one ISession per HttpRequest, although for the unit tests, I configured ThreadStaticSessionContext), it should work seamlessly. And after creating and binding an ISession, it hooks an event handler to the HttpContext.Current.ApplicationInstance.EndRequest event, which takes care of cleaning up the ISession after the request ends. (Of course, it only does this if it is really running in a web environment.) So, with all this set up, the NHibernateHelper will always be able to return a valid ISession, so there is no need to instantiate a Repository instance for the "unit of work" to operate properly. Instead, the Repository is a static class which operates with the ISession from the NHibernateHelper.CurrentSession property, and exposes some functionality through that. I'm curious, what do you think about this? Is it a valid way of thinking, or am I completely off track here?

    Read the article

1