What I ended up doing was this:
public class ValidationSetupFilter : IFilter
{
public bool Perform(ExecuteWhen exec, IEngineContext context,
IController controller,
IControllerContext controllerContext)
{
if (exec == ExecuteWhen.BeforeAction)
{
// TODO: cache this System.Reflection use
var methods =
controller.GetType().GetMethods(BindingFlags.Instance |
BindingFlags.Public);
foreach (var info in methods)
{
var attrs =
info.GetCustomAttributes(typeof
(SetupValidationForAttribute), true);
foreach (SetupValidationForAttribute
attr in attrs)
{
controllerContext.PropertyBag[attr.Key] = attr.TypeToValidate;
}
}
}
return true;
}
}
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false,
Inherited = true)]
public class SetupValidationForAttribute : Attribute
{
public Type TypeToValidate { get; set; }
public string Key { get; set; }
public SetupValidationForAttribute(Type typeToValidate, string
keyInPropertyBag)
{
TypeToValidate = typeToValidate;
Key = keyInPropertyBag;
}
}
and then decorating controller actions where I need a type to be in
the property bag with the SetupValidationFor attribute. It worked ok,
though a way of caching the reflection would be an improvement I
guess.
I was going to try to do something similar to handle my server-side
validation (for example if JS is turned off, and later for more
business-rule-oriented stuff), but I don't think there's a way to get
at an action's parameter-values from a Filter, so I guess my other
option is an Interceptor with the IoC container.
On Oct 7, 9:44 pm, Gauthier Segay <[EMAIL PROTECTED]> wrote:
> > I have one question, however. I have an authentication-status shared
> > partial view that lives in my layout, and contains a form that posts
> > to my home-controller. However, it's possible that this sign-in form
> > could be rendered on a controller other than home. So how best to
> > furnish it with a typeof(UserAuthenticationDto) so that validation can
> > happen for it - in a Filter? That gets me to thinking it might be a
> > fun thing to introduce a TypesNeededForValidationFigurerOuterFilter
> > ( ;-) ) that will look at the action being performed, and figure out
> > whether it needs to put a DTO-type into the PropertyBag, and which
> > type it needs to be - I suppose this might be facilitated by an
> > Attribute on the action that takes a type as argument....? How does
> > that sound?
>
> I've hacked this by having strong typed dictionary adapter interfaces
> that all inherit IBaseViewModel (my base holder for view properties),
> then using a dedicated method to create the dictionary adapter that
> check if the type is IBaseViewModel then populate the required
> properties.
>
> This isn't free of shortcommings, but it fits the purpose for me.
>
> What you are describing with filters and action attributes seems
> interesting but I haven't had time to investigate such solution.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
