springframework-developer

[Springframework-developer] About MVC

[<yan...@ne...>]

All:

I read "Expert One-on-One - J2EE Design and Development" recently. It is one of the most excellent books I have ever read about enterprise app design.

But, as I think, there is a problem in its decision on MVC implementation. The proposed solution works very well in simple applications. But when it comes to complicated real application requirement, it seems it can not work properly at least according to current description. It needs extension.

The Problem:
In such complication applications as portal, every web page (I call it "Screen" in contrast with View in the MVC) must display a lot of information. Information is grouped in several independent parts (I call it a Screen Part, SP). Views are just SPs, not Screens.
When the user submit a form (or link to another Screen). Another Screen will be displayed as a response to the input. This new Screen may have a SP display the result of the user action and may have other SPs unrelated to this user action. The spring framework works very good at creating the result SP while not provide good mechanism to produce other unrelated Screen.
I will describe it in detail.

1. Let's examine what the "model" means. 
The "true", traditional model refers to domain model (DM). 
As explained in the "The MVC Triad" part of the book, "A model contains data displayed by a view. Models in web applications (as opposed to "true," traditional MVC) are usually dumb storage objects, such as value objects, that represent the result of a complete business operation. Once a controller completes its processing and selects a view to generate content, the model should contain all the data to display. " (I call this kind of model in web app view model, VM).

2. Who create the VM?
As DM always exists in the back ground, the only problem remain is who should take the responsibility to create the VM from DM. 
(Assumption: Every View has a VM. Every VM could be displayed by several kind of View.)
A user action (submission a form or following a link) is mapping to a controller. Does the controller know what the user expects to see in the result Screen? No. The controller only knows the result of the action (which is important in the result Screen selection). It doesn't know all other information the user expecting (e.g. information's unrelated to this action). That is a controller should only create the model for one view (a SP in the result Screen). So let the controllers create all the VM for the result Screen is impossible.

My solution:
Principle: Seperate the action controller with the view controller.
The action controller's responsibility is to process the user action and return the result model (contains only data related to this action) and the result Screen name.
The view controller's responsibility is creating the VM from the DM for a SP.

I agree with the book that the controller returned with a model and name of "view". But the model should only contain information related to the user action. And the name of "view" should be the name of Screen Model. But this controller is only action controller. 
Then use a ScreenModelResolver (rather than a ViewResolver) to resolve the Screen Model name to a Screen Model which contains a set of SP Model. Every SP has a view controller to create the VM for this SP. The Screen Model calls all SPs' controller to create their VMs.
Then use a ScreenResolver to get the concrete Screen and forward the request to this concrete Screen to create the response (by using any mechanism described in the book) and sent back to user.

As depicted in the attach files.

What about your opinion? 


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: [Springframework-developer] About MVC

[William G. T. Jr. <wg...@ru...>]

You seem to be describing a Portal which has two parts, 1) Portal 
Application which is responsible for aggregating Portlets (your screen 
parts) and targeting a request to a Portlet and 2) Portlet Container 
which is responsible for the lifecyle of Portlets.

Spring could be used to implement the Portal Application which would be 
very close to your Sequence Diagram and would call down into the Portlet 
Container to invoke a Portlet and get the SP.

Each Portlet is in essence a separate web app and could use the standard 
Spring MVC model with some slight modifications (e.g. only return markup 
fragment instead of a whole page).

Talk a look at Portlet API and uPortal.
http://www.jcp.org/aboutJava/communityprocess/review/jsr168/
http://mis105.mis.udel.edu/ja-sig/uportal/

later.
Bill


yan...@ne... wrote:

> All:
> 
> I read "Expert One-on-One - J2EE Design and Development" recently. It is one of the most excellent books I have ever read about enterprise app design.
> 
> But, as I think, there is a problem in its decision on MVC implementation. The proposed solution works very well in simple applications. But when it comes to complicated real application requirement, it seems it can not work properly at least according to current description. It needs extension.
> 
> The Problem:
> In such complication applications as portal, every web page (I call it "Screen" in contrast with View in the MVC) must display a lot of information. Information is grouped in several independent parts (I call it a Screen Part, SP). Views are just SPs, not Screens.
> When the user submit a form (or link to another Screen). Another Screen will be displayed as a response to the input. This new Screen may have a SP display the result of the user action and may have other SPs unrelated to this user action. The spring framework works very good at creating the result SP while not provide good mechanism to produce other unrelated Screen.
> I will describe it in detail.
> 
> 1. Let's examine what the "model" means. 
> The "true", traditional model refers to domain model (DM). 
> As explained in the "The MVC Triad" part of the book, "A model contains data displayed by a view. Models in web applications (as opposed to "true," traditional MVC) are usually dumb storage objects, such as value objects, that represent the result of a complete business operation. Once a controller completes its processing and selects a view to generate content, the model should contain all the data to display. " (I call this kind of model in web app view model, VM).
> 
> 2. Who create the VM?
> As DM always exists in the back ground, the only problem remain is who should take the responsibility to create the VM from DM. 
> (Assumption: Every View has a VM. Every VM could be displayed by several kind of View.)
> A user action (submission a form or following a link) is mapping to a controller. Does the controller know what the user expects to see in the result Screen? No. The controller only knows the result of the action (which is important in the result Screen selection). It doesn't know all other information the user expecting (e.g. information's unrelated to this action). That is a controller should only create the model for one view (a SP in the result Screen). So let the controllers create all the VM for the result Screen is impossible.
> 
> My solution:
> Principle: Seperate the action controller with the view controller.
> The action controller's responsibility is to process the user action and return the result model (contains only data related to this action) and the result Screen name.
> The view controller's responsibility is creating the VM from the DM for a SP.
> 
> I agree with the book that the controller returned with a model and name of "view". But the model should only contain information related to the user action. And the name of "view" should be the name of Screen Model. But this controller is only action controller. 
> Then use a ScreenModelResolver (rather than a ViewResolver) to resolve the Screen Model name to a Screen Model which contains a set of SP Model. Every SP has a view controller to create the VM for this SP. The Screen Model calls all SPs' controller to create their VMs.
> Then use a ScreenResolver to get the concrete Screen and forward the request to this concrete Screen to create the response (by using any mechanism described in the book) and sent back to user.
> 
> As depicted in the attach files.
> 
> What about your opinion? 
> 

Re: [Springframework-developer] About MVC

[Darren D. <da...@da...>]

On Tuesday 11 November 2003 12:53, William G. Thompson, Jr. wrote:
> You seem to be describing a Portal which has two parts

--snip--

> Each Portlet is in essence a separate web app and could use the standard
> Spring MVC model with some slight modifications

If the app really is a portal, then this is valid, but my impression was the 
OP was talking about instances where controllers have to return model data 
that is peripheral to the user's request, but still very definitely an 
integral part of the one web application.

For example, a controller may process a search request and return a model 
comprising a List of SearchResult objects.  The view still needs to be 
built with (for example) a left-side navigator that depends on database 
content.  Should every controller within the application be made aware of 
how to retreive this part of the model?

If I understand correctly, that's the sort of scenario being described..?

Best wishes,
-- 

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

Re: [Springframework-developer] About MVC

[Christophe V. <c.v...@pa...>]

On Tuesday 11 November 2003 21:30, Darren Davison wrote:
> On Tuesday 11 November 2003 12:53, William G. Thompson, Jr. wrote:
> > You seem to be describing a Portal which has two parts
>
> --snip--
>
> > Each Portlet is in essence a separate web app and could use the standard
> > Spring MVC model with some slight modifications
>
> If the app really is a portal, then this is valid, but my impression was
> the OP was talking about instances where controllers have to return model
> data that is peripheral to the user's request, but still very definitely an
> integral part of the one web application.
>
> For example, a controller may process a search request and return a model
> comprising a List of SearchResult objects.  The view still needs to be
> built with (for example) a left-side navigator that depends on database
> content.  Should every controller within the application be made aware of
> how to retreive this part of the model?
>
> If I understand correctly, that's the sort of scenario being described..?
>
> Best wishes,

You can handle such cases using the tiles support in Spring.

Define a component in tiles, and designate a ComponentControllerSupport 
subclass to it in your tiles config file, like this:

<definition name="name" page="/somepage.jsp" controllerClass="subclass of 
ComponentControllerSupport"/>

In that subclass, you fetch all the data that is required as the model for the 
view (the tiles component, which is a regular jsp page).

There is some info at www.springframework.org/docs/integration/tiles.html , 
but the controllers are not mentioned.

-- 
Kind regards,
Christophe Vanfleteren

Re: [Springframework-developer] About MVC

[Darren D. <da...@da...>]

On Tuesday 11 November 2003 22:21, Christophe Vanfleteren wrote:

> You can handle such cases using the tiles support in Spring.

correct, but perhaps the problem has a wider scope.  An app shouldn't be 
forced to use tiles to get around it IMO, nor do you want redundant and 
high maintenance code in every controller.  

Conceptually, the model that a controller returns should be capable of being 
added to (decorated) with the peripheral data as configured at the view 
level.  Something akin to a servlet Filter, or Sitemesh on steroids.  This 
would leave the controllers lean and focused solely on translating user 
requests into model/view combinations as they are presently.  The 
'model-decorators' are free to add to this combination the secondary stuff 
that is independant of the user request but which still may require the 
services of business and/or data objects.

Is there something already in Spring MVC that lends itself to this kind of 
behaviour?

Best wishes,

-- 

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

Re: [Springframework-developer] About MVC

[Darren D. <da...@da...>]

On Tuesday 11 November 2003 23:27, Darren Davison wrote:

> Is there something already in Spring MVC that lends itself to this kind
> of behaviour?

without really thinking this through much (since it's gone 1:30am and I have 
to be up again in 4 hours)..

If an interface..

public interface ModelReference {
    public Map getModel();
}

.. is implemented by some arbitrary business objects, then a view could be 
defined as..

<bean id="myVelocityView"
  class="org.springframework.web.servlet.view.velocity.VelocityView">
  <property name="templateName"><value>main.vm</value></property>   
  <!-- standard attribs -->
  <property name="attributes">
    <props>
      <prop key="title">A Velocity Page</prop>
    </props>
  </property>  

  <!-- new property: list of ModelReference implementing bus. objects -->
  <property name="references">
    <list>
      <ref external="myBean"/>
      <ref external="myOtherBean"/>
    </list>
  </property>           
</bean>


AbstractView is amended with the following (part pseudo-code)..

public abstract class AbstractView extends WebApplicationObjectSupport 
implements View {

  //added
  private Map referenceObjects = new HashMap();

  ...

  //added
  public final void setReferencesList(List references) {    
    for each list item
      get bean from app context if exists
      if bean instanceof ModelReference 
        call bean.getModel() 
        consolidate into referenceObjects field
      end
    end
  }

  //amended
  public final void render(Map model, HttpServletRequest request, 
HttpServletResponse response)
  
    ...
    Map mergedModel = new HashMap(this.staticAttributes);
    mergedModel.putAll(referenceObjects);
    mergedModel.putAll(model);
    ...
  }

}


 - The controller still has final say and can overwrite model values from 
the static list or the reference list

 - Arbitrary beans can now add to the model that a view renders on a per 
view basis taking advantage of whatever container resources or custom logic 
is required

 - multiple views can use the same ref objects via the hierarchical view 
structure

 - It's a kind of half-way house between static attributes and model data 
returned by the controller but as shown isn't parameterised so reasonably 
rigid

 - maybe the interface can be dropped and the actual method to call for any 
given bean can be specified in the config too.  One less dependency for the 
business object


Goodnight.


-- 

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

RE: [Springframework-developer] About MVC

[Alef A. \(JTeam\) <al...@jt...>]

> .. is implemented by some arbitrary business objects, then a 
> view could be 
> defined as..

Darren, I've been implementing something like this before, using the
reference data feature of the controllers, works like a charme. However,
It's the problem still is that you end up using _one_ model, where - in
e.g. a portlet - you would somehow want a per-portlet model, scoped,
like in tiles... In your solution, what if one of the beans returns an
entry in the model with the same key as the controller (or another
bean). They override...

The JSP spec does not have any features for scope besides the
app/session/request/page. That's why Tiles added the Tiles scope... But
it's kinda ugly, since it does not work with JSTL tags (jstl of course
does not know the tiles scope). You first have to push all entries in
the pet-tile scpoe to the page scope and them use 'em, argh...

It would however be nice if we could come up with something that's not
specific to views...

Alef

RE: [Springframework-developer] About MVC

[Alef A. \(JTeam\) <al...@jt...>]

> You can handle such cases using the tiles support in Spring.
Yup, indeed. The thing is however, that you're tying yourself in to
Tiles and JSP's then... I've always been looking at ways to solve this
problem without specifying view technologies, still no solutions
found...

> There is some info at 
> www.springframework.org/docs/integration/tiles> .html , 
> but 
> the controllers are not mentioned.
I'm working on documentation for MVC, this will be part of it as well...
The example however shows some tiles-component stuff to get you going.