[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Hardy Ferentschik updated HV-274: --------------------------------- Affects Version/s: 4.0.2.GA Fix Version/s: 4.1.0 Component/s: mapping engine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Emmanuel Bernard commented on HV-274: ------------------------------------- Then create an new Bean ValidatorFactory I don't see the problem here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Gunnar Morling commented on HV-274: ----------------------------------- I like the builder pattern approach. Sticking to the original pattern description from Bloch all the mandatory attributes (e.g. type) should be parameters of the addConstraint() method, otherwise users might forget to call the according method. Maybe one could have three methods addConstraintTo{Type|ToField|ToProperty}() which would each have the required parameters (constraint/type, constraint/type/field name, constraint/type/property name)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Emmanuel Bernard commented on HV-274: ------------------------------------- Mandatory parameters are nice and should be respected as much as possible but there are alternatives to what Josh Bloch describes. Here is an approach that simulates named parameters: in Hardy's approach you could make sure that onField and onGetter return types have no other method but ofType. Basically the sure is not done with the configuration unless it goes all the way through. Otherwise, why placing the constraint declaration in front in the API navigation? It prevents people from adding several constraints on a given field. {code} config .type(ShoppingCart.class) .addConstraint(MyClassConstraint.class) .getter("items") .addConstraint(Size.class) .withParameter("min", 0) {code} This might require a closing context method though (.configure(), .freeze(), ...) to know that the declaration of the last constraint is done. Not sure. withXXX / addYYY pairs are hard to code when they can be interchanged ie {code} constraint.withMessage("doom!").andParameter("heat", 2000) //or constraint.withParameter("doom!").andMessage("heat", 2000) {code} They require complex return type combinations, I would not go there. Finally, would there be a way to make parameters type-safe for the built-in and Hibernate Validator constraints as well as all the constraint definitions that play along. For each constraint X, we would get a companion class XDefinition that reproduces the parameter list and even potentially enforce mandatory parameters {code} config .type(ShoppingCart.class) .getter("items") .constraint(NotNullDefinition.class) .constraint(SizeDefinition.class) .min(3).max(10); .getter("price") .constraint(RangeDefinition.class) .min(0) .max(100) class SizeDefinition { OptionalInDefinition<SizeDefinition> min(int min) {...} OptionalInDefinition max(int max) {...} } class RangeDefinition { MaxContext min(int min) {...} public static class MaxContext { OptionalsInDefinition<?> max(int max) {...} } } {code} PS: this is a draft example it probably does not work and needs refinement. We could also add hardwired approaches to built-in types {code} config .type(ShoppingCart.class) .getter("items") .size().max(30) .notNull() .forGroups(MustBuy.class) {Code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Hardy Ferentschik commented on HV-274: -------------------------------------- {quote} Mandatory parameters are nice and should be respected as much as possible but there are alternatives to what Josh Bloch describes. Here is an approach that simulates named parameters: in Hardy's approach you could make sure that onField and onGetter return types have no other method but ofType {quote} That's the idea. In fact the mock classes I have behave like this. {{onField}} and {{onGetter}} would only allow {{ofType}}. Also the {{ConstraintBuilder}} helper class might not be such a stupid idea. {quote} Otherwise, why placing the constraint declaration in front in the API navigation? It prevents people from adding several constraints on a given field. {quote} That's true, but personally I think it "reads more fluid" ;-) the way I proposed in my first comment. I also don't like "endless chaining" and think it is ok to call {{addConstraint}} for each new constraint. It also avoids the additional {{.configure}} or {{.freeze()}} {quote} withXXX / addYYY pairs are hard to code when they can be interchanged ie constraint.withMessage("doom!").andParameter("heat", 2000) //or constraint.withParameter("doom!").andMessage("heat", 2000) They require complex return type combinations, I would not go there. {quote} The idea I had was not to allow the interchanging. You are loosing no functionality when enforcing first message, then message, payload and finally elements. In fact the constraint definitions become more consistent. Concrete means that, that only the first level would have a "with". {quote} Finally, would there be a way to make parameters type-safe for the built-in and Hibernate Validator constraints as well as all the constraint definitions that play along. {quote} Probably possible, but I would not go there. You still need the generic approach for custom constraints. Also a wrong constraint definition will fail immediately at startup of the application. I think that's fair enough. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Emmanuel Bernard commented on HV-274: ------------------------------------- {quote} That's true, but personally I think it "reads more fluid" the way I proposed in my first comment. I also don't like "endless chaining" and think it is ok to call addConstraint for each new constraint. It also avoids the additional .configure or .freeze() {quote} So {code} config.addConstraint( Size.class ).onField("items").ofType(ShoppingCart.class); config.addConstraint( NotNull.class ).onField("items").ofType(ShoppingCart.class); config.addValid( Size.class ).onField("items").ofType(ShoppingCart.class); {code} is more fluid, more liking and more readable than {code} config .type( ShoppingCart.class ); .onField("items") .addConstraint( Size.class ) .addConstraint( NotNull.class ) .addValid() {code} Be honest :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Emmanuel Bernard commented on HV-274: ------------------------------------- {quote} Probably possible, but I would not go there. You still need the generic approach for custom constraints. Also a wrong constraint definition will fail immediately at startup of the application. I think that's fair enough. {quote} What's bothering you with the type-safe alternative? You've got to admit it's much more readable than the string oriented API (esp if you hardcode built-in ones) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Emmanuel Bernard commented on HV-274: ------------------------------------- Ah that's interesting (exploring here) {code} Size size = config.createConstraintExplorer(Size.class); config .type( ShoppingCart.class ) .onField("items") .addConstraint( Size.class ) .message("Youhou!") .param( size.min(), 34) .param( size.max(), 100); T param(U first, U second); {code} It's not as readable as the generics approach nor the hardcoded one but it goes a long way, is much simpler to set up than the generics approach and does not force people to write their ConstraintDescriptor. Question: - how to deal with annotations accepting annotations as parameters -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com... ] Jakub Bednář commented on HV-274: --------------------------------- Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira