[2.0] One model with multiple forms which have different validation rules

558 views
Skip to first unread message

Leonard Punt

unread,
Apr 5, 2012, 7:14:00 AM4/5/12
to play-fr...@googlegroups.com
Hi,

I've a model class, there are multiple forms to create an object of this model class. Each form has its own validation rules. What would be the best way to handle this?

Example:
- A model class User
- In form1 the username is required
- In form2 the email adress is required
- In form3 both are required
- In form4 none are required

Note: I want to validate my forms, not the data that I'm persisting!

In Play1 I could: 'In a controller method, call methods on the controller’s validation field directly.', http://www.playframework.org/documentation/1.2.4/validation

Thanks!

Guillaume Bort

unread,
Apr 5, 2012, 8:42:07 AM4/5/12
to play-fr...@googlegroups.com
Best way is to create a Form class for each form.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/OSHroPIhK0oJ.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

--
Guillaume Bort

Leonard Punt

unread,
Apr 5, 2012, 9:12:10 AM4/5/12
to play-fr...@googlegroups.com
Forgot to mention that I'm using Java. So you mean that I should write some kinda 'form bean' class for each form? Sounds Strut-ish :P

Guillaume Bort

unread,
Apr 5, 2012, 9:28:54 AM4/5/12
to play-fr...@googlegroups.com
Well I don't see any better solution. Defining a representation for
each form you have with the according validation rules is the simplest
and cleanest way.

On Thu, Apr 5, 2012 at 3:12 PM, Leonard Punt <leona...@gmail.com> wrote:
> Forgot to mention that I'm using Java. So you mean that I should write some
> kinda 'form bean' class for each form? Sounds Strut-ish :P
>

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/Lkh3jSzwHQgJ.

Sietse de Kaper

unread,
Apr 5, 2012, 9:45:37 AM4/5/12
to play-fr...@googlegroups.com
You're right, you need some way to define the form and the corresponding validation rules. The Scala API to do this is very nice, leveraging some of the language features Scala provides.

However, the Java Forms API feels a bit clunky. It requires creating beans for every case, and then copying data from that bean once the binder and validator have done their thing.

I think this process would be a lot simpeler if validation rules could be added to the Form object, in addition to any bean validation already present on the model class. 

For example, in the case where a certain field is required in one case, but not in the other, the model would just not contain the annotation. Instead, a Constraints.Validator object would be added to the Form. This is more like how it used to work in Play 1.x, where you could call validation methods in addition to doing validation rules defined in the model class.


On Thursday, April 5, 2012 3:28:54 PM UTC+2, Guillaume Bort wrote:
Well I don't see any better solution. Defining a representation for
each form you have with the according validation rules is the simplest
and cleanest way.

On Thu, Apr 5, 2012 at 3:12 PM, Leonard Punt wrote:
> Forgot to mention that I'm using Java. So you mean that I should write some
> kinda 'form bean' class for each form? Sounds Strut-ish :P
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/Lkh3jSzwHQgJ.
>

--
Guillaume Bort

Guillaume Bort

unread,
Apr 5, 2012, 9:53:22 AM4/5/12
to play-fr...@googlegroups.com
> You're right, you need some way to define the form and the corresponding
> validation rules. The Scala API to do this is very nice, leveraging some of
> the language features Scala provides.
>
> However, the Java Forms API feels a bit clunky. It requires creating beans
> for every case, and then copying data from that bean once the binder and
> validator have done their thing.

Actually is it almost the same for both Java and Scala. In Scala you
define a form specifying names and validation functions, and the
apply/unapply function to bind/unbind the form value to your model
value.

In Java it feels less natural, but it is equivalent: a class with
fields and validation annotations, and methods to bind/unbind your
model value.

> https://groups.google.com/d/msg/play-framework/-/S4IFt50fVcsJ.

Sietse de Kaper

unread,
Apr 5, 2012, 10:26:43 AM4/5/12
to play-fr...@googlegroups.com


On Thursday, April 5, 2012 3:53:22 PM UTC+2, Guillaume Bort wrote:
> You're right, you need some way to define the form and the corresponding
> validation rules. The Scala API to do this is very nice, leveraging some of
> the language features Scala provides.
>
> However, the Java Forms API feels a bit clunky. It requires creating beans
> for every case, and then copying data from that bean once the binder and
> validator have done their thing.

Actually is it almost the same for both Java and Scala. In Scala you
define a form specifying names and validation functions, and the
apply/unapply function to bind/unbind the form value to your model
value.

In Java it feels less natural, but it is equivalent: a class with
fields and validation annotations, and methods to bind/unbind your
model value.


Yes, I agree that the approaches are very similar, but I still think the Java API feels clumsy and inflexible. 

Like Leonard said, creating specific form beans and copying data to an from them is a very Struts-y, and exactly the kind of thing that Play freed us from. It would help if the structure could be (partly) de-coupled from the validation logic somehow. Right now binding is very tightly coupled to validation.
Reply all
Reply to author
Forward
0 new messages