Announcement Announcement Module
No announcement yet.
Servlet & portlet packages (SimpleFormController) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Servlet & portlet packages (SimpleFormController)

    I would like to discuss step by step refactoring and generalization of servlet package.
    In Spring Petclinic Application doc I see:
    "Spring is a collection of small, well-focused, loosely coupled Java frameworks..."
    could somebody that answer to me about loosely coupling in core of spring.
    Example 1 (SimpleFormController)
    What responsibilities of this class I see:
    1. HttpServletRequest provider (see methods referenceData, showForm,suppressValidation and so on).
    a. Need this to me in portlet package? Answer: No
    b. Need this for me in all my servlet controllers? Answer: Not always
    c. Can I use logic that not depends on java.servlet package in portlet package? Answer: No.

    2. subclasses of AbstractFormController:
    AbstractListFormController, AbstractParamListFormController, AbstractWizardFormController, SimpleFormController

    what for all of them is common? Control of workflow. I think for all of them will be enough to implement WorkflowController that knows about all possible states (for SimpleFormController it's is form and success page, for WizardController it's is pages and so on) and transition controllers. In so cases request provide information about state to which user would like to pass and transition controllers are trying to do it in order that was defined in config file. Usually it's ValidatorTransitionController, BusinessLogicTransitionController (that should to implement developer itself). Each transition controller can switch transition to other state. For some so controller we configure interceptors that will prepare all additional information (for example for ValidatorTransitionController need BindInterceptor, CommandInterceptor that get command from worklow context or create new instance).
    All these different responsibilities was putted to one class - SimpleFormController. This class provide a lot of properties bindOnNewForm, sessionForm,commandName,commandClass,validators,va lidateOnBinding,messageCodesResolver and take upon oneself factory responsibilities base on them (as for command, so validators, binder and so on).
    What does mean onBindAndValidate method? It will be more decoupled if we publish property for graph of workflow and define that for transition between "form" and "successView" define chain of controller [ValidatorTransitionController, ...] with interceptors (BindInterceptor, CommandInterceptor ) for ValidatorTransitionController.
    If you look on this method:
    protected final ServletRequestDataBinder bindAndValidate(HttpServletRequest request, Object command) that you will see
    if (this.validators != null && isValidateOnBinding() && !suppressValidation(request)) {
    that means only that by some not trivial callback methods we would like only to know - have we or not for this specific transition validate or not. It will be more simple and understandable if we point in config file that for this transition apply this transition controller, but for other - other.
    Who explaine to me this method: isFormSubmission? Transition between pages is not submission?

    3. In showForm method we have:
    request.getSession().setAttribute(getFormSessionAt tributeName(), errors.getTarget());
    in getCommand method:
    Object formObject = session.getAttribute(getFormSessionAttributeName() );
    session.removeAttribute(getFormSessionAttributeNam e());
    is it enough clean? I am not sure. Here we are using http session as workflowContext, that for any specific user session of working with specific workflow should be unique. This workflow context framework should to provide in start point and destroy when user arrive any end point.

    How many classes like AbstractParamListFormController we are going to implement? What they do? They only try to implement some specific NOT EXTENDABLE graph of workflow with very intresting comments:
    For now, only session mode works due to the use of the handleInvalidSubmit method. The parent class should be modified a bit for working without Session.
    We can simple remove this classes if refactor base classes and each developer that use spring can configure WorkflowController for any workflow that define business logic.

    3. ModelMergeInterceptor
    We have not bad referenceData method that provide model about which knows controller. But it's not the same that need for view. For some view that can be used with this controller need some additional information for others - other. Who to provide additional data? I think this should be implement in the following way:
    a. for state1 we define controllers that control transition to state2
    b. for state2 we define interceptors on entrance that controll environment in this state. They can publish any additional information into model/workflow context that may be need in view for this state or need in future (workflow context)

    What do you think about this?