So, for discussion purposes, enter < http://java.apache.org/turbine/pullmodel.html >

Specifically:

will describe as the "Pull MVC Model". What this entails is the ability to create an object that is able to "pull" the required information out at execution time within the template. Thus, it becomes the job of the template designer to understand the API of objects available to him/her to take advantage of.

use for each and every screen, there is instead a set of a few objects available for the template designer to pick and choose from. These objects will provide methods to access the underlying information either from the database or from the previously submitted form information.

Let's now think of the "API" as a business logic bean on your Action Form. Or a small number of coherent business logic beans that might be reasonably present on a given ActionForm.

Then to access a given property, using the 10-JAN+ nested-property syntax, a HTML form designer might refer to apiModule1.thisProperty or apiModule2.thatProperty

Now some of these "API beans" might be unique to a user (userPreferences.name), and others might be application-wide (actionMapping.login), and some might be relative to a given page-view, but to the page designer, they would all have a common "address space", that can be easily documented and understood.

Of course, many of the API-bean methods could also be encapsulated in custom tags, to make things even easier on the page designer. But it might be helpful to have everything in a central place first, and optimize/customize from there.

If developed in concert with a "conventional" application, it might also be possible for the API-beans to use a common interface and nomenclature, and share a great deal of code, with a traditional UI. (Since, of course, the business-logic API beans themselves should not depend on the Struts framework.)

And, finally, to quote our Turbine friends, once again:

are probably saying "well, duh!." However, this is really not the model that has been encouraged so far within Turbine nor within other products such as XMLC (which actually operates *only* on the Push model), so I believe that it is somewhat uncharted territory for some people. The only products that I can think of right now that encourage this is JSP taglibs and Tea, however, I still feel as though they have missed the boat on this in one way or another.