[hibernate-issues] [Hibernate-JIRA] Commented: (HV-274) Write a programmatic mapping API for constraint declarations

Hardy Ferentschik (JIRA) noreply at atlassian.com
Wed May 12 07:46:24 EDT 2010


    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37076#action_37076 ] 

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.



> Write a programmatic mapping API for constraint declarations
> ------------------------------------------------------------
>
>                 Key: HV-274
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-274
>             Project: Hibernate Validator
>          Issue Type: New Feature
>          Components: engine
>    Affects Versions: 4.0.2.GA
>            Reporter: Emmanuel Bernard
>            Assignee: Hardy Ferentschik
>             Fix For: 4.1.0
>
>


-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list