Of course others have written custom attributes. The problem is that you're trying to make attributes do something they're just not really designed for.
Instead of approaching the problem from the attribute side, try coming at it from the Validator side. Take a look at the ValidatorContainerInterfaceValidationContributor (and specifically IValidatorContainerInterface), which will allow you to supply a custom ValidationPerformer, ValidationRegistry and ValidationRunner. With this combination, you can ensure the Validator is made aware of the need for IUserService validation process requirements. Or maybe I'm just out of my mind, and someone else should chime in... -rb -----Original Message----- From: castle-project-users@googlegroups.com [mailto:castle-project-us...@googlegroups.com] On Behalf Of Yannis Sent: Tuesday, February 09, 2010 11:00 AM To: Castle Project Users Subject: Re: Inject dependencies in custom validator attribute no i dont want to register it with the container - that would also not work. I could use the container or the common service location mentioned below but i dont want to couple the attribute with the process of looking up the service from some container. I want it to be a simple constructor SomeValidationAttribute(IUserService s) if the same attribute is used elsewhere (where a/the container is not avaialable) then this approach would still work. Can someone post how they have done this in the past? i cant imagine i m the only one writing custom attributes with the castle framework. thx On Feb 9, 6:30 pm, "G. Richard Bellamy" <rbell...@pteradigm.com> wrote: > #1: you return true to SupportsBrowserValidation, which can't be right, > since you're calling a service which can really only be Server-Side, since > it's accessing the persistence layer of your Model. > > #2: the ValidationAttribute(s) have no knowledge of the container unless you > supply that knowledge. If you want access to the implementation of > IUserService, I don't see how you're going to get it unless you use the > container (or, *gasp* create an instance yourself). In my opinion, it > doesn't make sense to register a ValidationAttribute with the container, > which is what it sounds like you're asking about... but somebody else may > have a different view (I'd love to hear it). To me, although this is a > validation process, the responsibility lies in the IUserService. > > -rb > > -----Original Message----- > From: castle-project-users@googlegroups.com > > [mailto:castle-project-us...@googlegroups.com] On Behalf Of Yannis > Sent: Monday, February 08, 2010 10:28 PM > To: Castle Project Users > Subject: Inject dependencies in custom validator attribute > > Hi all, > > I have spent over 2 days on this and havent found a good solution so > far so I think its time to ask the experts :) > > I have a user registration form and I would like to make sure that the > email/username entered doesnt already exist in the database. This is > clearly a validation issue so i thought of creating a validation > attribute to perform this task. > > currently i have the following code and i am trying to inject > IUserService. I know i could do hacks like IOC.Resolve<IUserService>() > in the getter but i would like to keep my code free from coupling it > with the container. thx a lot > > public class ValidateUniqueEmailAttribute : > AbstractValidationAttribute > { > private readonly String _Message; > > public ValidateUniqueEmailAttribute(String message) > { > _Message = message; > } > > public IUserService UserService { get; set; } > > public override IValidator Build() > { > var validator = new UniqueEmailValidator(UserService) > { ErrorMessage = _Message }; > ConfigureValidatorMessage(validator); > return validator; > } > } > > and > > public class UniqueEmailValidator : AbstractValidator > { > private IUserService _UserService; > > public UniqueEmailValidator(IUserService userService) > { > _UserService = userService; > } > > public override bool IsValid(object instance, object > fieldValue) > { > if (fieldValue == null) return true; > > return _UserService.EmailExists(fieldValue.ToString()); > } > > public override bool SupportsBrowserValidation > { > get { return true; } > } > } > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to castle-project-us...@googlegroups.com. > To unsubscribe from this group, send email to > castle-project-users+unsubscr...@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to castle-project-us...@googlegroups.com. To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to castle-project-us...@googlegroups.com. To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
