Example of Passive View design pattern using JSP and POJOs

Question

Im trying to understand how the Passive View design pattern works for simple web apps.

Can someone provide a simple example of this pattern using these requirements:

1. View is a JSP that prints HELLO WORLD!
2. Data is persisted in the data store as "hello world", call to retrieve data can be a stub
3. Provide example files for pieces (presenter, view, etc) and denote which piece of the pattern each file represents.
4. No frameworks/DSLs should be used other than jstl/el (which are optional)

Thanks

UPDATE 1: Adding my understanding of how this would be structured.

// Presenter; responsible for multiple "rendtions" of a particular view (show, index, edit, summary, etc.)

public class HelloWorldPresenter {
     private HttpServletRequest request;
     private DataStore dateStore;

     public HelloWorldPresenter(HttpServletRequest request) { 
        this.request = request;
        this.dataStore = DataStoreUtil.getDataStore(request); 
        // Do a bunch of other inits that all getXXXModels() will use
     } 

     public getShowModel() {
        HelloWorldShowModel model = new HelloWorldShowModel();         
        String tmp = makeLoud(this.dataStore.getMyData()); // Stub method          

        model.setText(tmp);
        return model;
     }

     private String makeLoud(String str) {
        return str.toUpperCase() + "!";
     } 
}

// Model used by view

public class HelloWorldShowModel { 
   private String text;
   public getText() { return this.text };
   public setText(String text) { this.text = text; }
}

// View show.jsp

<c:set var="model" value="new HelloWorldPresenter.getShowModel()"/>
${model.text} -> HELLO WORLD!

or

<% HelloWorldShowModel model = new HelloWorldPresenter(request).getShowModel() %>
<%= model.getText() %>

The things I'm unsure about are:

1. How the Presenter would be exposed to the View (JSP) since the View shouldnt know about the presenter. I may be mixing semantics though, and the HelloWorldShowModel (which is acting as a "ViewModel" of sorts, is what shouldnt know about the Presenter).

   1. Should I even have the HelloViewShowModel abstraction, or should I simply have a method getText() on my Presenter which is called within the JSP to get the requested text.

   2. If I do have multiple "views" for a resource (ex. Show, Index, Edit, Summary, etc.), should I have multiple Presenters? How should this logic be broken up? Multiple presenters that inherit from a Shared presenter? Should each presenter only be responsible for returning one ViewModel?

I've read through Fowlers articles as well as a number of other write-ups - the problem (for me) is they are written in the context of .NET apps, and I dont understand how all their objects get wired up.

I hope this will aleve concerns of me being "lazy" and looking for a "hand-out" answer :)

Answer 1

With the requirements you state I would say the pattern can't be implemented. If you consider the view to be a JSP then there are no means a controller could actively set any values of UI components. (To me this is the core of the pattern: the controller actually updates the view actively by setting values of input / output UI components, not the other way round (view getting fields from a model object). This can't be done with the above techniques as a JSP has no means to be accessesd this way.

It could be implemented in a web environment based on Javascript though. Consider your view being the DOM and your controller being a Javascript component. The JS controller has direct write access to the DOM and therefore could update single fields actively like the pattern suggests. To update / get the model the JS controller could talk to a server-side system e. g. based on a REST API via Ajax.

Answer 2

A plain templating solution like JSP cannot be used to offload all logic to controller, at least in real world cases. I think this kind of thing can be achieved with JSF.

If you want to learn about how things are done I recommend you to take a look at Spring MVC. It's source code can teach you a lot.