Minos needs registration module

[fabianbuch]

h2. Features

• Registration form where users can signup for the application
• Double-opt in mechanism for activations of accounts
• More data to a user depending on the applications need (e.g. adress data or configuration properties) * Easy-to use extension-points for extension-data * ArgumentResolver that can inject this data to request handlers \ Improved "my Account" page where userdata and extension-data can be edited

h2. Extension

To extend a User by additional data you should extend the entity UserData:

@Entity
public class MyUserData extends UserData {
  @Column 
  private String phoneNumber;

  @ManyToOne
  private Whatever whateverRef;

  // getters and setters omitted
}

The module comes with an controller that handles registration and activation requests. This controller must be supported by an implementation of UserDataService:

public class MyUserDataService implements UserDataService {

  @Override
  public UserData newUserData() {
    return new MyUserData();
  }

  @Override
  public Validator getUserDataValidator(UserData userData) {
    return new MyUserDataValidator();
  }

  @Override
  public String getRegisterExtensionPointViewName {
    return "/mymodule/userdata/register";
  }

  @Override
  public String getProfileExtensionPointViewName {
    return "/mymodule/userdata/profile";
  }
}

This service defines two methods: The @newUserData()@ method creates a new @UserData@ implementation that is used to back the registration formular. The Validator returned by @getUserDataValidator()@ is used later to validate @userData@ before saving it (at registration or when a user edits is data later). You get the @userData@ object that gets validated to perform checks (e.g. wether the @userData@ object is new) before deciding what validator to use.

The two methods returning ViewNames are used by the views of this module to include the parts of the view that handle the extension-data. These can be jsp-snippets:

?

Originally coined by Marc Kannegießer. Added as ticket to allow discussion in a more structured way.

[fabianbuch]

Comment of Oliver Gierke: I'd vote for a separate @WhateverAccount@ class with a reference to a user instead of the need to extend an entity class. What would be the purpose of the superclass at all?

It feels strange that we shall have a service that "configures" concerns of the view layer. All this stuff could be simply achieved through configuring an appropriately designed controller anyway. Furthermore I'd vote to have the registration form just capturing the standard @User@ information for the first draft and having a separate profile page (that will vary from application to application). This way, we can implement the registration process independently. Prematurely integrating the views should be delayed until we have a sophisticated solution for this topic.