Best way to implement common form functionality

[mhowell]

Hi all,

I have a bunch of form pages in my site that need to share some common functionality, ie. a common set of fields, validation, binding, back-end logic, etc. Each form also needs to have its own additional set of custom fields, validation, back-end logic that is specific to that form.

What I'd like to do is isolate the common functionality, and re-use it on each form in such a way that the 'custom' parts of each form would have minimal dependency on the 'common' part. Ideally there would be no dependencies, and the 'custom' parts could be re-used on their own without the 'common' parts. And of course I would still want to be able to use Spring goodies like binding, validation, etc.

What's the best way to do this?

I was thinking of something like this:

- write a form backing class for the common stuff, called e.g. CommonStuff, with get/set methods for all of the common fields
- add a property to the CommonStuff class to reference an Object that will be used as the form-backing object for the fields in the form that are not common, called e.g. customStuff
- this allows the custom form backing object to be completely independent of the common form backing object

- write a CommonStuffValidator that validates the common fields
- added a property to the CommonStuffValidator to reference another Validator object that is used to validate the fields in the form that are not common, called e.g. customValidator
- after validating the common fields in the normal way, CommonStuffValidator calls CommonStuff.getCustomStuff, and passes this object in a call to customValidator.validate()
- this allows the custom validator to be completely independent of the common validator

- write a CommonFormController to handle the 'common' part of the form
- write JSP fragment(s) that render the common parts of the form view

- for each concrete form, do the following:

- write a form backing object, as usual
- write a validator, as usual
- write a JSP form view that includes the 'common' JSP fragment(s), as well as the custom parts of the form
- write a subclass of CommonFormController that a) delegates onSubmit to its parent class so that the common logic gets executed, and then adds its own custom logic, b) adds its custom form backing object to the common one by calling setCustomStuff on the parent class's form backing object
- use Spring to wire an instance of the common validator to the custom validator using the 'customValidator' property, and then wire this validator to the custom form controller

You'll notice above that I haven't figured out how to maintain full independence between the controllers and views, but at least the form backing objects and validators are fully independent.

Any thoughts on this are appreciated.

Thanks,

Morley Howell

[stackie]

Would like to hear some thoughts on this too.

[F.Degenaar]

If the common part is rather constant over time (i.e. doesn't change too often), why not use inheritance?
One abstract form backing class providing the getters and setters for the common attributes, which can be extended with the custom attributes.
A validator class that validates those common attributes of the form backing class and then calls an abstract method validateCustomAttributes(...), which has to be implemented for each sub class.
The same principle could be applied to the controller.
Given your description, it seems like you will always have a set of view, form backing class, validator and controller for every form. Unless there is no custom logic inside the controller, it would'nt make sense to me to strive for independence between view and controller.

HTH

[stackie]

If the common part is rather constant over time (i.e. doesn't change too often), why not use inheritance?
One abstract form backing class providing the getters and setters for the common attributes, which can be extended with the custom attributes.
A validator class that validates those common attributes of the form backing class and then calls an abstract method validateCustomAttributes(...), which has to be implemented for each sub class.
The same principle could be applied to the controller.
Given your description, it seems like you will always have a set of view, form backing class, validator and controller for every form. Unless there is no custom logic inside the controller, it would'nt make sense to me to strive for independence between view and controller.

HTH

I'm having this exact issue at the moment and striving to have one form backing object for common form items like firstName, Surname, businessName etc. So with your solution would you have something like...

public abstract CommonFormValidator {

 getFirstname()
 setFirstname()
 getSurname()
 
 etc.


}

public CustomForm extends CommonForm {

   // custom fields   

}

public CommonFormValidator implements Validator {

  public boolean supports(Class clazz) {
        return CommonFormValidator.class.isAssignableFrom(clazz);
   }

  public void validate(Object target, Errors errors) {
     validateFirstname();
     validateSurname(); 
     
     validateCustomAttributes(target, errors);
  }

}

public CustomAttributeValidator extends CommonFormValidator {

    public void validateCustomAttributes(Object target, Errors errors)  {
           // validate stuff

     } 
}