Search Results

Search found 9 results on 1 pages for 'crice'.

Page 1/1 | 1 

  • Min Length Custom AbstractValidationAttribute and Implementing Castle.Components.Validator.IValidato

    - by CRice
    I see with the Castle validators I can use a length validation attribute. [ValidateLength(6, 30, "some error message")] public string SomeProperty { get; set; } I am trying to find a MinLength only attribute is there a way to do this with the out of the box attributes? So far my idea is implementing AbstractValidationAttribute public class ValidateMinLengthAttribute : AbstractValidationAttribute and making its Build method return a MinLengthValidator, then using ValidateMinLength on SomeProperty public class MinLengthValidator : Castle.Components.Validator.IValidator Does anyone have an example of a fully implemented IValidator or know where such documentation exists?? I am not sure what all the methods and properties are expecting. Thanks

    Read the article

  • MVC Paging and Sorting Patterns: How to Page or Sort Re-Using Form Criteria

    - by CRice
    What is the best ASP.NET MVC pattern for paging data when the data is filtered by form criteria? This question is similar to: http://stackoverflow.com/questions/1425000/preserve-data-in-net-mvc but surely there is a better answer? Currently, when I click the search button this action is called: [AcceptVerbs(HttpVerbs.Post)] public ActionResult Search(MemberSearchForm formSp, int? pageIndex, string sortExpression) {} That is perfect for the initial display of the results in the table. But I want to have page number links or sort expression links re-post the current form data (the user entered it the first time - persisted because it is returned as viewdata), along with extra route params 'pageIndex' or 'sortExpression', Can an ActionLink or RouteLink (which I would use for page numbers) post the form to the url they specify? <%= Html.RouteLink("page 2", "MemberSearch", new { pageIndex = 1 })%> At the moment they just do a basic redirect and do not post the form values so the search page loads fresh. In regular old web forms I used to persist the search params (MemberSearchForm) in the ViewState and have a GridView paging or sorting event reuse it.

    Read the article

  • MS Test : How do I enforce exception message with ExpectedException attribute

    - by CRice
    I thought these two tests should behave identically, in fact I have written the test in my project using MS Test only to find out now that it does not respect the expected message in the same way that nunit does. nunit (fails): [Test, ExpectedException(typeof(System.FormatException), ExpectedMessage = "blah")] public void Validate() { int.Parse("dfd"); } ms test (passes): [TestMethod, ExpectedException(typeof(System.FormatException), "blah")] public void Validate() { int.Parse("dfd"); } No matter what message I give the ms test, it will pass. Is there any way to get the ms test to fail if the message is not right? Can I even create my own exception attribute? I would rather not have to write a try catch block for every test where this occurs.

    Read the article

  • ASP.NET MVC Filters: How to set Viewdata for Dropdown based on action paramter

    - by CRice
    Hi, Im loading an entity 'Member' from its id in route data. [ListItemsForMembershipType(true)] public ActionResult Edit(Member someMember) {...} The attribute on the action loads the membership type list items for a dropdown box and sticks it in viewdata. This is fine for add forms, and search forms (it gets all active items) but I need the attribute to execute BASED ON THE VALUE someMember.MembershipTypeId, because its current value must always be present when loading the item (i.e. all active items, plus the one from the loaded record). So the question is, what is the standard pattern for this? How can my attribute accept the value or should I be loading the viewdata for the drop down in a controller supertype or during model binding or something else? It is in an attribute now because the code to set the viewdata would otherwise be duplicated in each usage in each action.

    Read the article

  • How To Query Many-to-Many Table (one table's values becomes column headers)

    - by CRice
    Given this table structure, I want to flatten out the many-to-many relationships and make the values in the Name field of one table into column headers and the quantities from the same table into column values. The current idea which will work is to put the values into a Dictionary (hashtable) and represent this data in code but im wondering if there is a SQL way to do this. I am also using Linq-to-SQL for data access so a Linq-to-SQL solution would be ideal. [TableA] (int Id) [TableB] (int id, string Name) [TableAB] (int tableAId, int tableBId, int Quantity) fk: TableA.Id joins to TableAB.tableAId fk: TableB.Id joins to TableAB.tableBId Is there a way I can query the three tables and return one result for example: TableA [Id] 1 TableB [Id], [Name] 1, "Red" 2, "Green" 3, "Blue" TableAB [TableAId], [TableBId], [Quantity] 1 1 5 1 2 6 1 3 7 Query Result: [TableA.Id], [Red], [Green], [Blue] 1, 5, 6, 7

    Read the article

  • ASP.NET MVC Filters: How to set Viewdata for Dropdown based on action parameter

    - by CRice
    Hi, Im loading an entity 'Member' from its id in route data. [ListItemsForMembershipType(true)] public ActionResult Edit(Member someMember) {...} The attribute on the action loads the membership type list items for a dropdown box and sticks it in viewdata. This is fine for add forms, and search forms (it gets all active items) but I need the attribute to execute BASED ON THE VALUE someMember.MembershipTypeId, because its current value must always be present when loading the item (i.e. all active items, plus the one from the loaded record). So the question is, what is the standard pattern for this? How can my attribute accept the value or should I be loading the viewdata for the drop down in a controller supertype or during model binding or something else? It is in an attribute now because the code to set the viewdata would otherwise be duplicated in each usage in each action.

    Read the article

  • AutoMapper : Site wide usage of IValueFormatter for given types

    - by CRice
    It is my understanding I can configure AutoMapper in the following way and during mapping it should format all source model dates to the rules defined in the IValueFormatter and set the result to the mapped model. ForSourceType<DateTime>().AddFormatter<StandardDateFormatter>(); ForSourceType<DateTime?>().AddFormatter<StandardDateFormatter>(); I get no effect for my mapped class with this. It only works when I do the following: Mapper.CreateMap<Member, MemberForm>().ForMember(x => x.DateOfBirth, y => y.AddFormatter<StandardDateFormatter>()); I am mapping DateTime? Member.DateOfBirth to string MemberForm.DateOfBirth. The formatter basically creates a short date string from the date. Is there something I am missing when setting the default formatter for a given type? Thanks public class StandardDateFormatter : IValueFormatter { public string FormatValue(ResolutionContext context) { if (context.SourceValue == null) return null; if (!(context.SourceValue is DateTime)) return context.SourceValue.ToNullSafeString(); return ((DateTime)context.SourceValue).ToShortDateString(); } }

    Read the article

  • Difference in techniques for setting a stubbed method's return value with Rhino Mocks

    - by CRice
    What is the main difference between these following two ways to give a method some fake implementation? I was using the second way fine in one test but in another test the behaviour can not be achieved unless I go with the first way. These are set up via: IMembershipService service = test.Stub<IMembershipService>(); so (the first), using (test.Record()) //test is MockRepository instance { service.GetUser("dummyName"); LastCall.Return(new LoginUser()); } vs (the second). service.Stub(r => r.GetUser("dummyName")).Return(new LoginUser()); Edit The problem is that the second technique returns null in the test, when I expect it to return a new LoginUser. The first technique behaves as expected by returning a new LoginUser. All other test code used in both cases is identical.

    Read the article

1