[Springframework-developer] Re: About MVC

[Darren D. <dda...@kg...>]

Resurrecting this from a few days back, and to recap; 

Views often need access to 'secondary level' model data to decorate the data
returned by the controller, which is highly specific to the user gesture that
triggered that controller.  ie, a form post triggers a search controller to
obtain and return a list of results based on the user's input criteria, but
the view wants to wrap those results with a navigation menu and some latest
news - all of which are dependent on different business data or logic, and
none of which have anything to do with the search controller.  This is not a
portal, where the semantics are very different.  Tiles solves it, but Tiles is
view-technology specific.  View decoration is specific to a view and should be
configurable at the view definition level.  Although in practice, many views
may use the same 'decoration', this is solved already with parent view
definitions.

I took a look at Juergen's additions to  the view classes that enable a Map of
context objects to be added in the same way as static attributes.  This helps
go some way towards solving what I see the problem is, but it's not the whole
answer.

If the context object is itself not the secondary model data you wish to make
available to the view, but rather is a business object capable of retreiving
or generating that data, then something further needs to happen.  While
Velocity and JSP may be able to call a method on the object it's possibly not
desirable for them to do so, and other view technologies can't.  The options
would be to make the object some sort of FactoryBean (? not sure about this)
or implement another specific interface that the View can use to pull data
from the object.  Initially I mooted the other interface method but in fact
neither of these may be desirable or even possible if it's an existing
business component doing the work.

Specifying the method name to call for each object in the Map is another
option, but I guess this would break the current beans DTD for an
XmlViewResolver and would be difficult to parameterise.  Even so, this would
be closest to a view-technology agnostic (but view specific) solution I think.
 Anyone else?

--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp