Pull MVC

[Ted Husted <ne...@husted.com>]

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

Specifically:

>So, beginning with Scarab, we are going to try another model which I
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. 

>Instead of the developer telling the designer what Context names to
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:

> I hope that this makes sense to everyone. I'm sure that some of you
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. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/

Re: Pull MVC

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ted Husted wrote:

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

"Imitation is the sincerest form of flattery."  :-)

Seriously, the problems that Pull Model solves for Turbine apps was the primary
motivation for implementing nested and indexed property handling in Struts.

It's going to get even better if we succeed in implementing property getters
that can transparently access information from a tree of Java objects (the
current model), a JDBC RowSet, or an XML DOM structure -- all *transparently* to
the page designer.  For more powerful accessing capabilities, I also want to
look at XPath expressions -- again, with the underlying data architecture being
transparent, so that the business logic developers can remodel things to their
heart's content.

The only agreements that will be needed between business logic developers and
page developers are the names of the action mappings, the names (and scopes) of
the relevant beans, and the access paths to the relevant properties.

Craig McClanahan