Re: problem with MVC pattern

Lew wrote:


K Gaur wrote:


No.


In the servlet code that says,

   else if(music[0].length()==0){

you add the test:

   else if ( music == null || music.length == 0 )
   {
     ...
   }
   else if(music[0].length()==0){


The logic above, for example, could be placed in a validate() or isValid()
method of a Validator type implementor:

   public interface Validator
   {
     public boolean isValid( Map < String, String []> params );
   }

The controller would identify the source of the request from some
standardized, likely hidden form parameter:

<example>
  package controller;
  import ... ;
  public class Controller extends HttpServlet
  {
    private static final Map < String, Class< ? extends Validator>> validators
      = ControllerUtility.initializeValidators();

    protected void doPost(
      HttpServletRequest request,
      HttpServletResponse response )
    throws ServletException, IOException
   {
     doProcess( request, response );
   }

   private void doProcess(
      HttpServletRequest request,
      HttpServletResponse response )
    throws ServletException, IOException
   {
     String sourceView = request.getParameter( "sourceView" );
     Class< ? extends Validator> clazz = validators.get( sourceView );
     String destinView
     if ( clazz == null )
     {
       destinView = sourceView;
     }
     else
     {
      Validator validator = clazz.newInstance(); // try-catch needed
      destinView = ( validator == null? sourceView
           : ControllerUtility.lookupDestiny( sourceView,
                 validator.isValid( request.getParameterMap() )
             ));
     }
     RequestDispatcher rd = request.getRequestDispatcher( destinView );
     rd.forward( request, response );
   }
  }
</example>

Except for the omitted try-catch on the reflection this is pretty much how a
complete controller will look. Notice how the validation logic is completely
abstracted out of the controller. To add model logic, insert a
model.execute() step between the validation and the determination of
'destinView' (or whatever *your* variable name is). It uses the same pattern
- look up the mapping between outcomes and destination view based on the
configuration of the application. This can even be through external files, as
in Struts or Java Server Faces (JSF).

Only the control pattern is in this code. The actual logic is hidden behind
implementations of the Validator interface, and it would be similarly hidden
behind implementations of a ModelExecutor supertype.

   public interface Modeler
   {
     public static enum Outcome
     { SUCCESS, FAILURE, ERROR };
     public Outcome execute( Map < String, String []> parms );
     public Object getResult();
   }
   public abstract class ModelExecutor implements Modeler
   {
     // protected methods to provide scaffolding
   }

In the controller, you would add a
   ModelExecutor modeler = ControllerUtility.getModeler( sourceView );
   Modeler.Outcome outcome = modeler.execute( request.getParameterMap() );

and later
   request.setAttribute( "result", modeler.getResult() );

sometime before the rd.forward() call.

Thus your controller is actually quite brief, concerning itself solely with
matching validation and model logic with a source view, and likewise matching
a destination to the source and the outcome of its logic. The view named in
"destinView" is the URL of a JSP, solely concerned with presentation of the
data in the request attribute "result" (or whatever you name it). The logic
in the modeler instance does not care about the view, only how to get data
into an object that can be returned by getResult(). You have complete
separation of the M from the V from the C in MVC.

--
Lew