Using an array stored in params.yml to validate an entity - validation

I want to validate an entity using a values stored in an array which is in the params.
What I tried to do is injecting the array from params.yml (I'm using YAML) via service into a model.
In validation.yml, I tried to use the choice constraint with a callback. but I don't know how to call a method non-static from a different class.
To do this:
- Choice: { callback: [CountryHandler, getCountries] }
getCountries must be static.
Is it possible to do something like that with a method non static? Is it a better idea* to validate the entity with my own constraint as they explain here: http://symfony.com/doc/current/cookbook/validation/custom_constraint.html?
I only have to validate one param and at first sight it doesn't seems a good idea.

I think that is a better idea because you can re-use in other case and better readability. As show in the documentation you give, you must create 2 files, one for your validator and one for the constraint, if you have dependency, you can inject to Validator declaring a new service with dependancy declared as arguments. After this, you have only to call your constraint as another Constraint.

Related

spring integration returning-resultset based on payload

I'm calling procedure that returns different data in result set based on request type.
For this purpose I use stored-proc-outbound-gateway.
Request type is passed to procedure, but inside mapper it isn't available.
I could use ColumnMetaData to process resultSet, but I would prefer to have specific request type mappers.
Other solution is to have as many gateways as request types, but maybe there are something better.
Could I specify which mapper to use, based on payload, in stored-proc-outbound-gateway?
Well, to be honest if I were you I'd really make separate components for particular types. In the future the logic might be more complex and that would be easier to modify particular function than try to figure out how to come up with all those if..else.
Nevertheless your request is different...
As you see there is only one possible hook for you there - RowMapper injection for particular procedure param.
I can suggest the solution like RoutingRowMapper, which will consult some ThreadLocal variable to select the proper RowMapper to delegate.
The idea is picked up from the AbstractRoutingDataSource. Also there is something like SimpleRoutingConnectionFactory in the Spring AMQP.
The ThreadLocal you can populate before stored-proc-outbound-gateway and that really can be your desired type.
Another trick might be based on the result from the procedure where ResultSet contains a column with a hint which target RowMapper to choose.
In any way your task can be achieved only via composite RowMapper. The stored-proc-outbound-gateway doesn't have any logic to tackle and won't. It's just not its responsibility.

Get Class of Map in FreeMarker

I want to get a variable's class type in freemarker, used var.class.simpleName;
but if var is a Map, freemarker will process class as a key to find value in var.
it throw exception. how can I do this ? thanks for any suggestion.
First I have to ask why do you need that, because FreeMarker templates aren't supposed to know even if var is Map at all. Maybe your data-model is not what the template needs.
Anyway, for now, I would write a custom TemplateMethodModelEx for this purpose, something that you can use like ${classOf(var)}. Inside the TemplateMethodModelEx implementation you will receive a TemplateModel as the argument value, and then you can check if it's an AdapterTemplateModel, and if so you can get back the original object and get its class. (If it's not a AdapterTemplateModel, then it perhaps isn't even a wrapped Java object, so it doesn't make sense to ask what the class of the original object is.) However, the DefaultObjectWrapper with incompatibleImprovements set to less than 2.3.22 doesn't give AdapterTemplateModel to wrapped Map-s... so in 2.3.21 you will still have to use BeansWrapper, but you can at least set simpleMapWrapper to true.
In 2.3.22 it will be actually possible to write ${var?api.class}... you might use the nightly build. Though it only supposed to solve the problem where you can't access business methods because the primary type of the business class is Map.

acceptable MVC parameter usage

would it be considered a valid implementation if I do not use the model for certain parameters? For example a webform posting values directly to the controller which then passes them to another class. Is it necessary to make sure that all the fields in the webform are also referenced/stored in the model?
I consider it a valid implementation, but suggest that you do this only if the parameters you want to exclude from the Model are absolutely NOT going to be used by the View (other than for confirmation of data entry in your webform), AND there is no need for the parameters to be referenced again once handled by the Controller.
Yes, it would work, strictly speaking.
However, you probably want to use the model. You don't want to create a new variable every time you run the view, which would happen if you use the controller.
I would consider it valid implementation if you decided not to use the model for certain parameters. I believe there are instances where certain fields may not relate directly to the model in question therefore giving valid reason to break those fields/parameters off from the model.

Modify Getter and Setter with Database First Approach

I'm currently learning ASP.Net MVC 3 with Entity Framework and want to know if there's a way to modify getter and setter for the model class generated by using the database first approach. Say, I want to sanitize HTML in the model's getter and setter to make sure there's no invalid code get saved in database. What's the best way to do that?
Thanks before.
You will want to use your custom validation routine. The class will be populated automatically, its up to you to determine then if its valid or not.
Use IValidateableObject or override the ValidateEntity method to handle your own validatations.
See Julie's article at:
http://msdn.microsoft.com/en-us/data/gg193959.aspx
In the edmx diagram you can edit the properties of a, well, property, one of which is the access modifier:

Where to implement cross-entity-validation?

I have a project where the data-model and business-layer are located in two different modules. Of course, the bussiness-module has a dependency to the model-module. The entity-validation is implemented through java-validation-api annotations.
I'm wondering where I should implement the cross-entity-validation (business validation, where the relations between different entity types are validated). Currently I see the follwing options:
Create custom javax.validation.ConstraintValidators and associated annotations. Problem is, that the validator would need access to the business-services, i.e. to retrieve related entities, but the model-module should not have a dependency to the business-module.
Implement cross-entity-validation in the business-services persist/merge-methods (i.e. by using interceptors). That would be possible, but the cross-entity-validation is seperated from the entity-validation and I would like to have only one place for validation.
Which option is preferable? Are there any better suggestions?
Thanks,
Sebastian
From the ideological point of view approach 1. is better. Bean Validation is working at the level of Model (in Model-View-Controller) and it is nothing wrong if Model part talks to database. So, for instance, you can create DAOs, which can be used both by service leayer and Model validators in order to avoid code duplication.
Interceptors are also good place to validate something, but you will not be able to use full power and automaticity of Bean Validation. Probably you will need to call validate method on your model objects by hand, throw ConstraintViolationException where needed, etc. Doable, but a little bit of work. In addition some validation probably will be left in Model, so, as you've pointed out, there would be more then one place, where validation is going on.
So I would move necessary DB code to separate layer and go with option 1.

Resources