Localization within an MVC project

Hi there,

I try to localize the validation error messages. So far I managed to localize the LS resources, but I have some problems to properly localize the entity properties. I implemented the IDisplayNamingStrategy and assigned it the LightSpeed context. For attached entites this is working fine, but for detached entities (new ones) I end up with half localized error messages.

I would like to avoid passing an invalid entity down to my repository only to get localized property names. Is there any chance that an entity can somehow access a IDisplayNamingStrategy even when it is detached?

Another thing: I wrote a new "LightSpeedMvcValidatorProvider" which has a new property DisplayNamingStrategy of type IDisplayNamingStrategy. The provided LightSpeedMvcValidatorProvider calls DataAnnotationBuilder by using the metadata.PropertyName as the displayName parameter (the last parameter). "DataAnnotationBuilder.GetDataAnnotations(metadata.ContainerType, metadata.PropertyName, metadata.PropertyName);"

My implementation uses the a IDisplayNamingStrategy property to get the proper displayName value and therefore creates the correct localized error messages. I am happy to provide the source.

The problem is the "LightSpeedEntityModelBinder". Within the "BindModel" it checks the "entity.IsValid" which results to half localized error messages.

Within the LightSpeedEntityModelBinder.BindModel there a two parts which have (in my point of view) issues:

1. That part uses some english words for a check:

   if (!entity.IsValid) { foreach (ValidationError validationError in entity.Errors) { if (!validationError.ErrorMessage.EndsWith("is invalid")) bindingContext.ModelState.AddModelError(validationError.PropertyName ?? "Custom", validationError.ErrorMessage); } }

I guess the "EndsWith" check will not working in other languages - right?

1. This line creates an Entity instance - No support for IoC containers: Entity entity = bindingContext.Model == null ? (Entity)Activator.CreateInstance(bindingContext.ModelType) : (Entity)bindingContext.Model;

Is there any chance that an entity can somehow access a IDisplayNamingStrategy even when it is detached?

That's not really possible at the moment. An entity can exist in complete isolation; there's no concept of an 'ambient' context. You would need to implement custom validations with your own error messages, or create a class that encapsulates a dummy UOW so you could temporarily attach entities to that without bringing them into a full-on repository.

We do have a longer-term goal to decouple validation from persistence, and the behaviour you want would probably follow from that, but for now I'm afraid the two are fairly closely related. I'll have a think about whether we can kludge in a way for validators to access an 'ambient' context but no promises.

I'll follow up with our MVC chap on the model binder issues.

For the error message filtering, if we implemented an approach where you could register a set of filters which could be run in place of that static filtering that occurs at the moment would that sound acceptable for the situations you are looking at - I am thinking you would need to register these either statically with the model binder or as an overload to the .Register() method and it will then be used for all model binding operations after that.

Something like

EntityModelBinder.Register(typeof(MyEntity).Assembly, new List<EntityModelBinderFilter>() { 
  new EntityModelBinderFilter(Filter.StartsWith, "Error starts with"), 
  new EntityModelBinderFilter(Filter.EndsWith, "error ends with.") 
});

In regards to the initialization of the Entity instance, the model binder is expecting to be working with a class based off Entity so we are either going to assign it from the model coming through on the context or we need to construct one at the time. Are you thinking you would want this construction to be done by an IoC container?

Jeremy

To make it clear: The problem is when a post request comes in through the LightSpeedEntityModelBinder.

@Ivan,

The validation for checks that don't need to access the database can run right now without a UOW. So the Validation system needs access to a DisplayStrategy. Otherwise it is not localizable and the implementation/usage of the DisplayStrategy and falls too short (in a detached context like the LightSpeedEntityModelBinder) - not good.

@Jeremy,

1. IEntityFactory (http://www.mindscapehq.com/forums/thread/3535) is not considered during the creating of a new Entity (Activator.CreateInstance(...)).
2. Your proposal with the static registration to filter out that messages sounds feasible. Can you please tell me which validations creates theses error messages your are filtering out there.

May be you can provide a hook to create a UOW, attach the entity for validation and than detach it?

Hmm, creating a UOW and attaching the entity would by pass my architecture.

The best solution for me would be that I can register a DisplayStrategy for the validation system in a way that the Modelbinder can uses it.

I really don't want to see some database access (unique checks) at the Modelbinding stage.

Any news on that?

I have added the two changes and these are now available in the nightly builds.

LightSpeedEntityModelBinder.Register() now has additional overloads which allow you to pass through an IEntityFactory which you want to use for entity initialization (typically you would be passing through Context.EntityFactory if you are handling your Context globally) and/or a list of LightSpeedEntityModelBinderFilter registrations which will perform the error filtering in place of the existing hard code string comparison.

So an example of registering both of these would look like this:

LightSpeedEntityModelBinder.Register(
        typeof(Entity1).Assembly,
        MvcApplication.LightSpeedContext.EntityFactory,
        new List<LightSpeedEntityModelBinderFilter>()
        {
          new LightSpeedEntityModelBinderFilter(LightSpeedEntityModelBinderFilterType.StartsWith, "City"),
          new LightSpeedEntityModelBinderFilter(LightSpeedEntityModelBinderFilterType.EndsWith, "Name is required")
        });

So you can then use the filters in conjunction with your localized strings as required.

By default the Filter set is registered as:

new List<LightSpeedEntityModelBinderFilter>()
{
  new LightSpeedEntityModelBinderFilter(LightSpeedEntityModelBinderFilterType.EndsWith, "is invalid")
};

To answer your other question, the "is invalid" string is added as an error message when an entity or collection are not valid, so you will see these when any association off the entity is invalid which will likely be because the parent is invalid so you can end up with a large chain of these which are not relevant for display purposes. These dont relate to any particular rule but can be localized by localizing the following two resources in Mindscape.LightSpeed.dll:

• IsInvalid (default value is: {0} is invalid)
• CollectionItemInvalid (default value is: {0} item {1} is invalid)

Jeremy

Thanks for that!

What is not clear for me, are the property names within the error messages now be translated via the IDisplayNamingStrategy?

Any chances that you extend the ValidationContext to register a IDisplayNameStrategy?

Something like that:

public sealed class ValidationContext
{
   ...
   public static IDisplayNamingStrategy FallbackDisplayNameStrategy { get; set; }

  ... 
   public string TargetName
   {
     get
     {
       if (_unitOfWork == null)
       {
         if (FallbackDisplayNameStrategy != null)
         {
           return FallbackDisplayNameStrategy.GetDisplayName(FieldModel.HumanName, _entity.GetType());
         }
         return FieldModel.HumanName;
       }
       return _unitOfWork.Context.DisplayNamingStrategy.GetDisplayName(FieldModel.HumanName, _entity.GetType());
     }
   }

...
}

In that way the property Names can be translated in almost every situations, not only at the LightSpeedModelBinder.

Sörnt

No there have not been any changes re: IDisplayNamingStrategy yet - Ill have a look into this and let you know if we can make an update.

Jeremy

Hi Jeremy,

any news regarding to the ValidationContext?

Sörnt

Hi Sörnt,

I have added this in largely as you have suggested, although the property name to set on ValidationContext is called DisconnectedDisplayNameStrategy. This will be available in the next nightly build for you.

Jeremy

Thank you very much, Jeremy!

Sörnt