MVP, FieldGroup and BeanValidation

Hi!

My question is not only Vaadin related, but since it arises with using FieldGroup and BeanValidation, I was hoping that someone here can help me.

I’m trying to use the MVP pattern with databinding of my JPA entities to forms. When I add BeanValidation to my entities, my beans get validated before the FieldGroup commits the new values. But because I am using a presenter for the logic, the entity is not directly saved in the “postCommit”, instead I call presenter.save(…) there. So I have a public “save” method in my presenter, and in that method I don’t know if the entity really has been validated, I would have to “trust” the UI.

What would be the best practice in this case? Validation only in the presenter’s save-method (but then the FieldGroup must alreay be committed)? Or validation in the UI and in the presenter? Or moving the CommitHandler to the presenter and make the save-method private (would make testing harder) ?

Kind regards,
Hannes

That’s a tough one. What I would do, is let the View handle runtime validation and delegate the save-button directly to the presenter along with the FieldGroup. The presenter may then call commit() (which validates fields again) and handle any error situations. Since the FieldGroup isn’t technically a UI component, this solution wouldn’t break the pattern either :slight_smile:

Thank you for your answer. Your proposal sounds good to me, and I will try and see “what it looks like”. Although I don’t really like to have Vaadin-dependencies in my presenter - but who has ever exchanged the view-framework …

Hello, as you’re using BeanValidation your backend should automatically revalidate the contents of entities when they’re being stored to the database. This way you get “double validation” out of the box. I’d have suggested that from your view you call presenter’s “saveButtonPressed()” and presenter will then call view’s commit() and store for backend service in charge of entity management.

This way you would not have the Vaadin dependencies.

Another option is as you mentioned having the CommitHandler implemented in the presenter that would then call save(). I find this better than passing the entire FieldGroup to presenter.

As Thomas said, this is tough one and there’s probably not the right answer. Go what goes best with your implementation style and keep it consistent meaning that in other cases do the same as well.

Personally I think presenter should have method that initiates the storing process when listener is invoked in the View. View should have clear enough interface which is not Vaadin dependent that would provide needed changes. Then it’s presenter’s responsibility to deal with the bakcend service and for example in case of rollback would call proper error handling method in the view interface.

Thank you. It seems to be really hard to find a clean solution :wink:
Another problem is validation of dependent fields of my FieldGroup, e.g. if field A has some value, field B must have some appropriate value. I cannot validate this after “commit”, because then I cannot “discard” in case of an error. On the other hand it is not really nice to use the FormGroup properties to do the validation instead of using the bean’s getters.
I think it is the “discard”-function I like most of the FieldGroup, because otherwise I would have to reload my entity from the database, and its also not so easy to replace it in the table’s container.

To sum up, FieldGroup’s “commit” and “discard” together with BeanValidation could be really nice, but it seems to be hard (for me) to use it in a clean way.

I’m not entirely sure but I think it should be possible to perform bean validation to whole type instead of just one property. For this you will probably have to create your own custom annotation and validation implementation. This way you might be able to create validator that depends on multiple properties.

Thank you. I already thought about doing something like this.