1. CustomModelBinderAttribute -> GetBinder()
2. IModelBinder -> BindModel()
3. ActionFilterAttribute -> OnActionExecuting()
4. ActionFilterAttribute -> OnActionExecuted()
5. ActionFilterAttribute -> OnResultExecuting()
6. ActionFilterAttribute -> OnResultExecuted()

(As of Beta 1)

        public ActionResult Binder(Dog dog)

        {

            return View("Index");

        }

Here's the model:

    public class Dog

    {

        public string Name { get; set; }

        public Dog cat { get; set; }

    }

Calling this action will cause a stack overflow error, as the default model binder will attempt to recreate every dog in the chain.

I would not have noticed this as I use my own implementation of the model binders to provide functionality for pulling an entity from NHibernate that is passed by ID via Ajax. The problem is that I recently switched over to the [Transaction]/ATM method of managing transactions with NHibernate. The problem with this method is that it creates a dynamic proxy of your controller so it can intercept the transaction. In doing so it looses the method argument attributes and then - boom - stack overflow. So now I'm off to hack YET ANOTHER open source project to see if I can get it to not remove the method parameter attributes. :(

For this example I'm designing a new table in the management tool, using a bit field to indicate if a pet is dead or not. (Nevermind the obvious flaw that there are several types of dead.) Obviously I want a default value of NOT-DEAD or as we like to call it around here: 0.


Ok, no problems so far. Lets put in some sample data:

Wait a minute now. You mean that when I specify the default value I must put a zero, but when I enter data into the table I have to type out 'false/true' for every entry? Ohh, and just in case you're curious no, you can't type 'false/true' in for the default value.
I'm sure none my readers would ever do anything like this. :)

(All 5 of you.)

If you think there is something wrong with this approach please let me know. :)

public class SessionCache<T>

    {

        private ISession sn;

        private IList<T> entities;

        private void ValidateSession(ISession session)

        {

            if(sn == session)

                return;

            sn = session;

            entities = new List<T>();

        }

        public void Add(ISession session, params T [] entity)

        {

            ValidateSession(session);

            foreach (T t in entity)

            {

                if(!Equals(t, default(T)) && !entities.Contains(t))

                    entities.Add(t);

            }

        }

        public void Remove(T entity, ISession session)

        {

            ValidateSession(session);

            if(entities.Contains(entity))

                entities.Remove(entity);

        }

        public T[] GetEntities(ISession session)

        {

            ValidateSession(session);

            return entities.ToArray();

        }

        public void Clear()

        {

            if(entities != null)

                entities.Clear();

        }

    }

I thought I'd mention it to this group so that people were aware of this difference between the interaction the old ParameterBinders and Rescues in version 4 and the new ModelBinders and HandleErrorAttributes of version 5.

The new way of doing parameter binding expects all errors to be placed into the ModelStateDictionary specified in the GetValue method.
public override object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState) {

The ModelStateDictionary can then be checked in the controller for errors via ViewData.ModelState.IsValid

I think the idea is that multiple binding errors can then be reported to the user at one time:
foreach (var value in ViewData.ModelState.Values)
{
value.Errors.....
}

Unfortunatly our current NameValueDeserializer that is used by the DeserializeAttribute throws exceptions when it encounters errors. These exceptions are NOT caught by Rescues / HandleErrorAttributes. The ControllerActionInvoker (in preview 5) calls

IDictionary parameters = GetParameterValues(methodInfo);

before the try/catch block that passes off errors to the HandleErrorAttributes. So if you're using any kind of attribute deserialization and expecting your exceptions to be displayed all pretty like in your rescues... then move line #177 to line #180 of your ControllerActionInvoker.cs :)

-Will

        public static void Save(this ISession session, params object [] entities)

        {

            foreach (var o in entities)

            {

                session.Save(o);

            }

        }

You can use it like:

session.Save(a,b,c,d,....);

with a list of objects of any type. Useful for unit testing where you want to save multiple items at once.

[Update]

Probably should call it something other than Save, such as SaveAll or SaveList because if you only pass two items to the overload it calls the standard Save(object, int id) version. :(

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: Attempting to parse a null value into an sql string.

Examine your mappings for abstract classes that aren't implemented, or classes that are marked as abstract in the mappings but not in the c# file. I was refactoring out some abstract classes in the middle and forgot to delete the abstract="true" line in the mapping.