In fluentvalidation you can either send the object to validate and options specifying the rulesets to run, or you can create a validationcontext and include additional data via RootContext. In my current situation, I need to do both. I need to include additional data on the RootContext and specify what validations to run. I am manually creating the validator as it is needed. Can this be accomplished?
Since a moderator deleted my answer. The following link explains how to setup the context, including the rule sets that need to be applied.
https://github.com/FluentValidation/FluentValidation/issues/1165
In short you create a rule set factory instance that is passed into the context constructor.
Related
In the API I'm putting together, I perform an Action over a set of entities. The issue I'm having is how to allow the action to vary depending on the client's preferences and supported methods.
Some of the action types will need the client to provide additional options: for instance, one of the actions will result in an email being sent, so the client needs to provide the body, recipients and so on. The server may know about more action types than the client does. For instance, a new sending method could be added, but an old client isn't going to know how to set up the options for it. As well as that, there are action types that require no options from the client, and hence all clients can use that as soon as the server is enabled for it.
As well as varying the action types based on those supported by the client/server, the entities selected also have an effect -- some entities are not valid for some action types.
At the end of this negotiation, the client (ultimately the end user) is free to choose from any of the 'no-option' action types applicable to these entities, or any of the 'need-options' action types applicable to these entities, and supported by both the client and the server.
Actions are triggered by setting a status field to committed or similar.
My thoughts so far are to provide a generic DoAction resource, with a sub-collection of the entities. A property on this resource lets you specify the 'ActionType'. There is then another sub-resource called ActionOptions and it's this where you either set the options for the particular type you're using, or leave it empty for 'no-option' types.
The issue I'm having is to decide if this is the best approach, or if something involving content types would be better, and also how to negotiate the list of available action types for the client, including the no-option types which the client can support even if it doesn't explicitly know about it.
I decided to add two read-only collections to the DoAction resource, one listing the no-option action types, and one listing the need-options types (plus could optionally include schema-like info there). These collections are based on the entities included.
The client sets their action type and the options, which is a dynamic key/value store. When the status is changed to committed, that's an opportunity to validate the resource prior to performing the action.
It seems that Spine's Model.updateAttributes only updates attributes, and does not create new ones in case you supply any.
In my usecase, I have a controller that creates part of the attributes. Then through an Ajax request the server responds with the full object, and I want to update the model instance living in Spine with the additional variables.
For example, I have a model with attributes: name, date_created. Through the controller a user instantiates an object providing only the name. An Ajax request notifies the server which in turn responds with a name and a date_created. This date_created should then be added to the user's model.
Model.updateAttributes doesn't work, and I wouldn't be too fond of deleting the object and creating a new one - that just seems as too much overhead. I could provide default values for variables that are not set upon creation, but that also has a negative side. I guess what I'm looking for is a method that could be called Model.createOrUpdateAttributes. Can anybody recommend a way to achieve this? Thanks!
I might haven't fully understood your usecase, but I'll try to answer.
You need to declare whatever attributes a type of a model has with the configure class method. This declaration helps various model function to do their job later.
After you declare all the attributes you need, you can create model instances with any of the previously declared attributes.
You don't have to provide values for all the declared attributes.
After the ajax call returns, the date_created will be set on your model instance. Until this happens it will be just undefined.
If this solution still can't work for you, please describe why, and I'll gladly try to help.
I am trying to run some code on objects that are loaded from RavenDB, and I need to do it just after the object has been loaded with its property values.
I've tried intercepting the deserialization process using a CustomCreationConverter and overriding ReadJson, but the object I can access at that point has all the properties set, except the one I need : the Id. Is there somewhere else I can slot into the pipeline in order to do this?
The reason you don't see the Id is because it's not part of the document, it's in the metadata as #id.
If you want to intercept client side, you can register a custom Conversion Listener. Create a class that implements IDocumentConversionListener and register it with documentStore.RegisterListener(). In the DocumentToEntity method, you can run your custom logic. The documentation is lacking on Listeners in general, but there is another topic that also uses them:
http://ravendb.net/kb/16/using-optimistic-concurrency-in-real-world-scenarios
The other option would be to add a bundle that intercepts on the server side. For that, you would use a Read Trigger.
Long post - sorry....
I'm doing input validation for a WCF service and using StructureMap IoC to instantiate the appropriate validation objects.
I have 2 different validation groups:
Per object validation: means that one input parameter, will be resolve by the Ioc (e.g. Ioc.ResolveAll<IValidatorObject<InputParameter1>, .... <InputParameter2>... etc). If any rules are found, the validate method is invoked.
Per context validation: mean that validation rules are invoked, based on the current context (explicit roles). A context could be 'deposit money' or 'open bank account'. Context validation are usually dependent on 2 or more of the input parameters and is the key difference between object and context validation.
The input validation is performed in the BeforeCall event call in the IParameterInspector (provider/server side!). With this event I get a string containing the operation name (aka. the context) and an object[] with the input parameters.
The problem is that there's multiple validation rules for a single context and the only way I have figured out to register the context in the Ioc, is by using named intances. However I can only register 1 named instance pr. interface. And the interface is not uniquely identifiable by its signature. E.g.
Context rule for 'create account': IValidatorContext<User, Account>
Context rule for 'deposit money': IValidatorContext<User, Account>
So my question is, whether it is possible to register the context in StructureMap in any other way than named instances - or maybe a way to group named instances.
An alternative route, is to implement explicit interfaces for each context, so that the DepositMoney service method might look like this:
public Response Deposit(IDepositMoney inputArguements)
where IDepositMoney contains the input parameters.
So am I way off here, or can I somehow register a context in StructureMap? Or should I just go ahead and use explicit interface instead (3rd option?)
Thanks in advance
Ended up wrapping each set of input parameters in a context and used the context to register in StructureMap. Works like a charm!
The whole idea of named instances is that the name points to a single instance, so you won't be able to use that feature to do what you are trying to achieve. I would use explicit interfaces, since this will allow you to auto wire more things and have less calls to your container.
I have a situation where I want to dependency inject my user object, but also place the current user in the IoC container. I want the following lines to work:
kernel.Get<User>(); // Should return a new User()
kernel.Get<User>("Current"); // Should return the current user
One might think bindings like this would work:
Bind<User>().ToSelf();
Bind<User>().ToMethod(LoadCurrentUser).InRequestScope().Named("Current");
Of course, that gives:
Ninject.ActivationException: Error activating User
More than one matching bindings are available.
Activation path:
1) Request for User
Suggestions:
1) Ensure that you have defined a binding for User only once.
I understand the error since a Named binding does not restrict the application of that binding, so both bindings apply. It seems clear that I need to use the contextual bind with the .When*() methods but I can't come up with any way to do that. I feel like there should be when methods that detect whether a named instance is applied. Something like:
// Not valid Ninject syntax
Bind<User>().ToSelf().WhenUnnamedRequested();
Bind<User>().ToMethod(LoadCurrentUser).WhenNamedRequested().InRequestScope().Named("Current");
I can't find any place on the IRequest interface or it's properties that tells me the name requested. How do I do this?
This question was answerd on the mailing list:
http://groups.google.com/group/ninject/browse_thread/thread/cd95847dc4dcfc9d?hl=en
If you are accessing the user by calling Get on the kernel (which I hope you do not) then give the first binding a name as well and access User always by name. Actually, there is a way to get an instance from the binding without a name. But because I heartily recommend not to do this, I do not show how to to this here. If you still want to do it this way I'll tell you later how this would work.
If you are doing it the better and prefered way and inject the user to the objects that require it as dependency there are two options:
The easier one: Give the first binding a name and add a named attribute to the parameters e.g. ctor([Named("NewUser") IUser newUser, [Named("Current")] IUser
currentUser)
Or the prefered way to keep the implementation classes free of the IoC framework: Specify custom attributes and add them to the parameters e.g. ctor([NewUser] IUser newUser, [CurrentUser]IUser currentUser). Change the Bindings to:
Bind<User>().ToSelf()
.WhenTargetHas<NewUserAttribute>();
Bind<User>().ToMethod(LoadCurrentUser)
.InRequestScope()
.WhenTargetHas<CurrentUserAttribute>();