springframework-developer

RE: [Springframework-developer] About MVC

[<dar...@hs...>]

<Alef>
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...
</Alef>


yeah, that's actually the way I understood the OP's request - as being a
non-portal scenario, and in some (non-portal) apps it's definitely what
you'd want I think.  For portlets, you would of course need properly scoped
models but I think what was outlined has some validity.

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

Do you not think that configuring some of this peripheral data should be at
the view level?  If not the view, then where..? In common scenarios I come
across, the secondary model is quite specific to a view (though not of
course the TYPE of view)

Darren.




_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

Re: [Springframework-developer] About MVC

[<jue...@we...>]

Darren,

I don't know if you've noticed that I've added a related feature =
yesterday: AbstractView has now not  only the standard =
setAttributes(Properties) and setAttributesCSV(String) but also =
setAttributesMap(Map). The latter allows not only for String values but =
also for refs, lists, maps, and props as static model attributes.

To make refs work, I've reworked XmlViewResolver and =
ResourceBundleViewResolver to create their view bean factories as =
children of the surrounding application context. Else, you would not be =
able to reference beans in the application context from view =
definitions.

To not put beans themselves as static attributes into the model but =
rather other objects, maybe use a FactoryBean that returns the model =
attribute? The name of the attribute would be determined by the map key =
in the view definition then. It might still make sense to support a =
special ModelReference bean that creates a whole map of attribute =
key/value pairs.

And BTW, <ref external=3D"..."/> is somewhat deprecated as there is no =
strict check for just referencing external beans. <ref bean=3D"..."/> is =
now the generic one that can reference any bean in any reachable =
context, while <ref local=3D"..."/> can just reference local beans in =
the same XML file (via XML ids).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Wednesday, November 12, 2003 2:50 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] About MVC - Email
found in subject


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=20
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=20
defined as..

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

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


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

public abstract class AbstractView extends WebApplicationObjectSupport=20
implements View {

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

  ...

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

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

}


 - The controller still has final say and can overwrite model values =
from=20
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=20
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=20
returned by the controller but as shown isn't parameterised so =
reasonably=20
rigid

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


Goodnight.


--=20

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



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] About MVC

[<dar...@hs...>]

<Juergen>
I don't know if you've noticed that I've added a related feature yesterday:
AbstractView has now not  only the standard setAttributes(Properties) and
setAttributesCSV(String) but also setAttributesMap(Map). The latter allows
not only for String values but also for refs, lists, maps, and props as
static model attributes.
</Juergen>

Actually I wasn't aware when I scribbled down my thoughts.  Spooky!

I'll familiarise myself with it all pronto.

Regards,
Darren







_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

RE: [Springframework-developer] About MVC

[<dar...@hs...>]

<Alef>
From what I've seen there's three commons scenerio's

1. Reference data needed to render the view. This is the stuff we have
already.
2. Data related to the view but not necessarily needed to render it
(additional news in a sidebox, perhaps a menu).
3. Componentized views having corresponding controller (portlet)

The first case can perfectly be implemented using our current reference
data implementation (a list of elements in a select box of a form for
instance). One controller, having reference data, specifically belonging
to the controller

The second case (sideboxes containing news, a menu that needs
information not related to the main view) I consider to be a simple
Tiles approach and I think a somewhat more advanced version of the
reference data features we have now, would do. Something like you
proposed maybe. Reference data, however, not in fact related to the
controller!

The third case however, is a completely different one and somewhat looks
like the portlet approach. I think this is a bit too far-fetched to
implement in Spring, although I'd like to offer view-tech independent
stuff for this. Parallel controllers rendering views independent of
eachother.

It's just some rambling, but maybe we could brainstorm about this more
in order to come with something brilliant :)...
</Alef>

Hi Alef,

We're definitely on the same wavelength here, and you're right - it's the
2nd scenario that I was focusing on earlier.  Portlets are indeed a very
different kettle of fish.

As Juergen just mentioned, some changes were made yesterday co-incidentally
that I wasn't aware of, but which may facilitate efforts in this direction.
I'll go and see what's different and gather some more thoughts.

Cheers!
Darren.




_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

Re: [Springframework-developer] About MVC

[Yanger <yan...@ya...>]

SSBhZ3JlZS4NCkkgY2l0ZSBwb3J0YWwganVzdCBhcyBhbiBleGFtcGxlIGZvciB0aG9zZSBhcHBs
aWNhdGlvbnMgdGhhdCBoYXZlIHNvbWUgdW5yZWxhdGVkIGNvbnRlbnQgdG8gYmUgZGlzcGxheWVk
IGluIGRpZmZlbmVudCBwYXJ0cyBvZiBTY3JlZW4uIA0KDQoJCQkNCg0KQmVzdCBSZWdhcmRzLA0K
WWFuZ2VyDQp5YW5nZXIxOTk3QHlhaG9vLmNvbS5jbg0KCQkJCQkJCTIwMDMtMTEtMTQgMDY6NDE6
MzANCg0KPT09PT09PSAyMDAzLTExLTExIDIwOjUzOjU4IFlvdXIgbWFpbCBpc6O6PT09PT09PQ0K
DQo+WW91IHNlZW0gdG8gYmUgZGVzY3JpYmluZyBhIFBvcnRhbCB3aGljaCBoYXMgdHdvIHBhcnRz
LCAxKSBQb3J0YWwgDQo+QXBwbGljYXRpb24gd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIGFnZ3Jl
Z2F0aW5nIFBvcnRsZXRzICh5b3VyIHNjcmVlbiANCj5wYXJ0cykgYW5kIHRhcmdldGluZyBhIHJl
cXVlc3QgdG8gYSBQb3J0bGV0IGFuZCAyKSBQb3J0bGV0IENvbnRhaW5lciANCj53aGljaCBpcyBy
ZXNwb25zaWJsZSBmb3IgdGhlIGxpZmVjeWxlIG9mIFBvcnRsZXRzLg0KPg0KPlNwcmluZyBjb3Vs
ZCBiZSB1c2VkIHRvIGltcGxlbWVudCB0aGUgUG9ydGFsIEFwcGxpY2F0aW9uIHdoaWNoIHdvdWxk
IGJlIA0KPnZlcnkgY2xvc2UgdG8geW91ciBTZXF1ZW5jZSBEaWFncmFtIGFuZCB3b3VsZCBjYWxs
IGRvd24gaW50byB0aGUgUG9ydGxldCANCj5Db250YWluZXIgdG8gaW52b2tlIGEgUG9ydGxldCBh
bmQgZ2V0IHRoZSBTUC4NCj4NCj5FYWNoIFBvcnRsZXQgaXMgaW4gZXNzZW5jZSBhIHNlcGFyYXRl
IHdlYiBhcHAgYW5kIGNvdWxkIHVzZSB0aGUgc3RhbmRhcmQgDQo+U3ByaW5nIE1WQyBtb2RlbCB3
aXRoIHNvbWUgc2xpZ2h0IG1vZGlmaWNhdGlvbnMgKGUuZy4gb25seSByZXR1cm4gbWFya3VwIA0K
PmZyYWdtZW50IGluc3RlYWQgb2YgYSB3aG9sZSBwYWdlKS4NCj4NCj5UYWxrIGEgbG9vayBhdCBQ
b3J0bGV0IEFQSSBhbmQgdVBvcnRhbC4NCj5odHRwOi8vd3d3LmpjcC5vcmcvYWJvdXRKYXZhL2Nv
bW11bml0eXByb2Nlc3MvcmV2aWV3L2pzcjE2OC8NCj5odHRwOi8vbWlzMTA1Lm1pcy51ZGVsLmVk
dS9qYS1zaWcvdXBvcnRhbC8NCj4NCj5sYXRlci4NCj5CaWxsDQo+DQo+DQo+eWFuZ2VyMTk5N0Bu
ZXRzY2FwZS5uZXQgd3JvdGU6DQo+DQo+PiBBbGw6DQo+PiANCj4+IEkgcmVhZCAiRXhwZXJ0IE9u
ZS1vbi1PbmUgLSBKMkVFIERlc2lnbiBhbmQgRGV2ZWxvcG1lbnQiIHJlY2VudGx5LiBJdCBpcyBv
bmUgb2YgdGhlIG1vc3QgZXhjZWxsZW50IGJvb2tzIEkgaGF2ZSBldmVyIHJlYWQgYWJvdXQgZW50
ZXJwcmlzZSBhcHAgZGVzaWduLg0KPj4gDQo+PiBCdXQsIGFzIEkgdGhpbmssIHRoZXJlIGlzIGEg
cHJvYmxlbSBpbiBpdHMgZGVjaXNpb24gb24gTVZDIGltcGxlbWVudGF0aW9uLiBUaGUgcHJvcG9z
ZWQgc29sdXRpb24gd29ya3MgdmVyeSB3ZWxsIGluIHNpbXBsZSBhcHBsaWNhdGlvbnMuIEJ1dCB3
aGVuIGl0IGNvbWVzIHRvIGNvbXBsaWNhdGVkIHJlYWwgYXBwbGljYXRpb24gcmVxdWlyZW1lbnQs
IGl0IHNlZW1zIGl0IGNhbiBub3Qgd29yayBwcm9wZXJseSBhdCBsZWFzdCBhY2NvcmRpbmcgdG8g
Y3VycmVudCBkZXNjcmlwdGlvbi4gSXQgbmVlZHMgZXh0ZW5zaW9uLg0KPj4gDQo+PiBUaGUgUHJv
YmxlbToNCj4+IEluIHN1Y2ggY29tcGxpY2F0aW9uIGFwcGxpY2F0aW9ucyBhcyBwb3J0YWwsIGV2
ZXJ5IHdlYiBwYWdlIChJIGNhbGwgaXQgIlNjcmVlbiIgaW4gY29udHJhc3Qgd2l0aCBWaWV3IGlu
IHRoZSBNVkMpIG11c3QgZGlzcGxheSBhIGxvdCBvZiBpbmZvcm1hdGlvbi4gSW5mb3JtYXRpb24g
aXMgZ3JvdXBlZCBpbiBzZXZlcmFsIGluZGVwZW5kZW50IHBhcnRzIChJIGNhbGwgaXQgYSBTY3Jl
ZW4gUGFydCwgU1ApLiBWaWV3cyBhcmUganVzdCBTUHMsIG5vdCBTY3JlZW5zLg0KPj4gV2hlbiB0
aGUgdXNlciBzdWJtaXQgYSBmb3JtIChvciBsaW5rIHRvIGFub3RoZXIgU2NyZWVuKS4gQW5vdGhl
ciBTY3JlZW4gd2lsbCBiZSBkaXNwbGF5ZWQgYXMgYSByZXNwb25zZSB0byB0aGUgaW5wdXQuIFRo
aXMgbmV3IFNjcmVlbiBtYXkgaGF2ZSBhIFNQIGRpc3BsYXkgdGhlIHJlc3VsdCBvZiB0aGUgdXNl
ciBhY3Rpb24gYW5kIG1heSBoYXZlIG90aGVyIFNQcyB1bnJlbGF0ZWQgdG8gdGhpcyB1c2VyIGFj
dGlvbi4gVGhlIHNwcmluZyBmcmFtZXdvcmsgd29ya3MgdmVyeSBnb29kIGF0IGNyZWF0aW5nIHRo
ZSByZXN1bHQgU1Agd2hpbGUgbm90IHByb3ZpZGUgZ29vZCBtZWNoYW5pc20gdG8gcHJvZHVjZSBv
dGhlciB1bnJlbGF0ZWQgU2NyZWVuLg0KPj4gSSB3aWxsIGRlc2NyaWJlIGl0IGluIGRldGFpbC4N
Cj4+IA0KPj4gMS4gTGV0J3MgZXhhbWluZSB3aGF0IHRoZSAibW9kZWwiIG1lYW5zLiANCj4+IFRo
ZSAidHJ1ZSIsIHRyYWRpdGlvbmFsIG1vZGVsIHJlZmVycyB0byBkb21haW4gbW9kZWwgKERNKS4g
DQo+PiBBcyBleHBsYWluZWQgaW4gdGhlICJUaGUgTVZDIFRyaWFkIiBwYXJ0IG9mIHRoZSBib29r
LCAiQSBtb2RlbCBjb250YWlucyBkYXRhIGRpc3BsYXllZCBieSBhIHZpZXcuIE1vZGVscyBpbiB3
ZWIgYXBwbGljYXRpb25zIChhcyBvcHBvc2VkIHRvICJ0cnVlLCIgdHJhZGl0aW9uYWwgTVZDKSBh
cmUgdXN1YWxseSBkdW1iIHN0b3JhZ2Ugb2JqZWN0cywgc3VjaCBhcyB2YWx1ZSBvYmplY3RzLCB0
aGF0IHJlcHJlc2VudCB0aGUgcmVzdWx0IG9mIGEgY29tcGxldGUgYnVzaW5lc3Mgb3BlcmF0aW9u
LiBPbmNlIGEgY29udHJvbGxlciBjb21wbGV0ZXMgaXRzIHByb2Nlc3NpbmcgYW5kIHNlbGVjdHMg
YSB2aWV3IHRvIGdlbmVyYXRlIGNvbnRlbnQsIHRoZSBtb2RlbCBzaG91bGQgY29udGFpbiBhbGwg
dGhlIGRhdGEgdG8gZGlzcGxheS4gIiAoSSBjYWxsIHRoaXMga2luZCBvZiBtb2RlbCBpbiB3ZWIg
YXBwIHZpZXcgbW9kZWwsIFZNKS4NCj4+IA0KPj4gMi4gV2hvIGNyZWF0ZSB0aGUgVk0/DQo+PiBB
cyBETSBhbHdheXMgZXhpc3RzIGluIHRoZSBiYWNrIGdyb3VuZCwgdGhlIG9ubHkgcHJvYmxlbSBy
ZW1haW4gaXMgd2hvIHNob3VsZCB0YWtlIHRoZSByZXNwb25zaWJpbGl0eSB0byBjcmVhdGUgdGhl
IFZNIGZyb20gRE0uIA0KPj4gKEFzc3VtcHRpb246IEV2ZXJ5IFZpZXcgaGFzIGEgVk0uIEV2ZXJ5
IFZNIGNvdWxkIGJlIGRpc3BsYXllZCBieSBzZXZlcmFsIGtpbmQgb2YgVmlldy4pDQo+PiBBIHVz
ZXIgYWN0aW9uIChzdWJtaXNzaW9uIGEgZm9ybSBvciBmb2xsb3dpbmcgYSBsaW5rKSBpcyBtYXBw
aW5nIHRvIGEgY29udHJvbGxlci4gRG9lcyB0aGUgY29udHJvbGxlciBrbm93IHdoYXQgdGhlIHVz
ZXIgZXhwZWN0cyB0byBzZWUgaW4gdGhlIHJlc3VsdCBTY3JlZW4/IE5vLiBUaGUgY29udHJvbGxl
ciBvbmx5IGtub3dzIHRoZSByZXN1bHQgb2YgdGhlIGFjdGlvbiAod2hpY2ggaXMgaW1wb3J0YW50
IGluIHRoZSByZXN1bHQgU2NyZWVuIHNlbGVjdGlvbikuIEl0IGRvZXNuJ3Qga25vdyBhbGwgb3Ro
ZXIgaW5mb3JtYXRpb24gdGhlIHVzZXIgZXhwZWN0aW5nIChlLmcuIGluZm9ybWF0aW9uJ3MgdW5y
ZWxhdGVkIHRvIHRoaXMgYWN0aW9uKS4gVGhhdCBpcyBhIGNvbnRyb2xsZXIgc2hvdWxkIG9ubHkg
Y3JlYXRlIHRoZSBtb2RlbCBmb3Igb25lIHZpZXcgKGEgU1AgaW4gdGhlIHJlc3VsdCBTY3JlZW4p
LiBTbyBsZXQgdGhlIGNvbnRyb2xsZXJzIGNyZWF0ZSBhbGwgdGhlIFZNIGZvciB0aGUgcmVzdWx0
IFNjcmVlbiBpcyBpbXBvc3NpYmxlLg0KPj4gDQo+PiBNeSBzb2x1dGlvbjoNCj4+IFByaW5jaXBs
ZTogU2VwZXJhdGUgdGhlIGFjdGlvbiBjb250cm9sbGVyIHdpdGggdGhlIHZpZXcgY29udHJvbGxl
ci4NCj4+IFRoZSBhY3Rpb24gY29udHJvbGxlcidzIHJlc3BvbnNpYmlsaXR5IGlzIHRvIHByb2Nl
c3MgdGhlIHVzZXIgYWN0aW9uIGFuZCByZXR1cm4gdGhlIHJlc3VsdCBtb2RlbCAoY29udGFpbnMg
b25seSBkYXRhIHJlbGF0ZWQgdG8gdGhpcyBhY3Rpb24pIGFuZCB0aGUgcmVzdWx0IFNjcmVlbiBu
YW1lLg0KPj4gVGhlIHZpZXcgY29udHJvbGxlcidzIHJlc3BvbnNpYmlsaXR5IGlzIGNyZWF0aW5n
IHRoZSBWTSBmcm9tIHRoZSBETSBmb3IgYSBTUC4NCj4+IA0KPj4gSSBhZ3JlZSB3aXRoIHRoZSBi
b29rIHRoYXQgdGhlIGNvbnRyb2xsZXIgcmV0dXJuZWQgd2l0aCBhIG1vZGVsIGFuZCBuYW1lIG9m
ICJ2aWV3Ii4gQnV0IHRoZSBtb2RlbCBzaG91bGQgb25seSBjb250YWluIGluZm9ybWF0aW9uIHJl
bGF0ZWQgdG8gdGhlIHVzZXIgYWN0aW9uLiBBbmQgdGhlIG5hbWUgb2YgInZpZXciIHNob3VsZCBi
ZSB0aGUgbmFtZSBvZiBTY3JlZW4gTW9kZWwuIEJ1dCB0aGlzIGNvbnRyb2xsZXIgaXMgb25seSBh
Y3Rpb24gY29udHJvbGxlci4gDQo+PiBUaGVuIHVzZSBhIFNjcmVlbk1vZGVsUmVzb2x2ZXIgKHJh
dGhlciB0aGFuIGEgVmlld1Jlc29sdmVyKSB0byByZXNvbHZlIHRoZSBTY3JlZW4gTW9kZWwgbmFt
ZSB0byBhIFNjcmVlbiBNb2RlbCB3aGljaCBjb250YWlucyBhIHNldCBvZiBTUCBNb2RlbC4gRXZl
cnkgU1AgaGFzIGEgdmlldyBjb250cm9sbGVyIHRvIGNyZWF0ZSB0aGUgVk0gZm9yIHRoaXMgU1Au
IFRoZSBTY3JlZW4gTW9kZWwgY2FsbHMgYWxsIFNQcycgY29udHJvbGxlciB0byBjcmVhdGUgdGhl
aXIgVk1zLg0KPj4gVGhlbiB1c2UgYSBTY3JlZW5SZXNvbHZlciB0byBnZXQgdGhlIGNvbmNyZXRl
IFNjcmVlbiBhbmQgZm9yd2FyZCB0aGUgcmVxdWVzdCB0byB0aGlzIGNvbmNyZXRlIFNjcmVlbiB0
byBjcmVhdGUgdGhlIHJlc3BvbnNlIChieSB1c2luZyBhbnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBp
biB0aGUgYm9vaykgYW5kIHNlbnQgYmFjayB0byB1c2VyLg0KPj4gDQo+PiBBcyBkZXBpY3RlZCBp
biB0aGUgYXR0YWNoIGZpbGVzLg0KPj4gDQo+PiBXaGF0IGFib3V0IHlvdXIgb3Bpbmlvbj8gDQo+
PiANCj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+VGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBBcGFjaGVDb24g
MjAwMywNCj4xNi0xOSBOb3ZlbWJlciBpbiBMYXMgVmVnYXMuIExlYXJuIGZpcnN0aGFuZCB0aGUg
bGF0ZXN0DQo+ZGV2ZWxvcG1lbnRzIGluIEFwYWNoZSwgUEhQLCBQZXJsLCBYTUwsIEphdmEsIE15
U1FMLA0KPldlYkRBViwgYW5kIG1vcmUhIGh0dHA6Ly93d3cuYXBhY2hlY29uLmNvbS8NCj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj5odHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0
cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+Lg0KDQo9ID0gPSA9ID0gPSA9
ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCg0KDQo=

[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

RE: [Springframework-developer] About MVC

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

> Do you not think that configuring some of this peripheral 
> data should be at the view level?  If not the view, then 
> where..? In common scenarios I come across, the secondary 
> model is quite specific to a view (though not of course the 
> TYPE of view)

From what I've seen there's three commons scenerio's

1. Reference data needed to render the view. This is the stuff we have
already.
2. Data related to the view but not necessarily needed to render it
(additional news in a sidebox, perhaps a menu).
3. Componentized views having corresponding controller (portlet)

The first case can perfectly be implemented using our current reference
data implementation (a list of elements in a select box of a form for
instance). One controller, having reference data, specifically belonging
to the controller

The second case (sideboxes containing news, a menu that needs
information not related to the main view) I consider to be a simple
Tiles approach and I think a somewhat more advanced version of the
reference data features we have now, would do. Something like you
proposed maybe. Reference data, however, not in fact related to the
controller!

The third case however, is a completely different one and somewhat looks
like the portlet approach. I think this is a bit too far-fetched to
implement in Spring, although I'd like to offer view-tech independent
stuff for this. Parallel controllers rendering views independent of
eachother.

It's just some rambling, but maybe we could brainstorm about this more
in order to come with something brilliant :)...

Alef

RE: [Springframework-developer] About MVC

[Lars F. <lar...@gm...>]

I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".

IMO the main advantage of WebWork is that it's very easy to understand even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.

The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.

What do you think about this ?

Regards,
Lars

> > Do you not think that configuring some of this peripheral 
> > data should be at the view level?  If not the view, then 
> > where..? In common scenarios I come across, the secondary 
> > model is quite specific to a view (though not of course the 
> > TYPE of view)
> 
> >From what I've seen there's three commons scenerio's
> 
> 1. Reference data needed to render the view. This is the stuff we have
> already.
> 2. Data related to the view but not necessarily needed to render it
> (additional news in a sidebox, perhaps a menu).
> 3. Componentized views having corresponding controller (portlet)
> 
> The first case can perfectly be implemented using our current reference
> data implementation (a list of elements in a select box of a form for
> instance). One controller, having reference data, specifically belonging
> to the controller
> 
> The second case (sideboxes containing news, a menu that needs
> information not related to the main view) I consider to be a simple
> Tiles approach and I think a somewhat more advanced version of the
> reference data features we have now, would do. Something like you
> proposed maybe. Reference data, however, not in fact related to the
> controller!
> 
> The third case however, is a completely different one and somewhat looks
> like the portlet approach. I think this is a bit too far-fetched to
> implement in Spring, although I'd like to offer view-tech independent
> stuff for this. Parallel controllers rendering views independent of
> eachother.
> 
> It's just some rambling, but maybe we could brainstorm about this more
> in order to come with something brilliant :)...
> 
> Alef
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] About MVC

[Mike Cannon-B. <mi...@at...>]

Lars,

For what it's worth we're working on some WW2 / Spring integration at the
moment (along the lines of what Juergen, Cameron and others have suggested)
- including minor modifications to XW to support external references, and
then a Spring external reference resolver. I think it will work very nicely,
we'll keep you posted :)

Cheers,
Mike

ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support

On 12/11/03 9:32 PM, "Lars Fischer" (lar...@gm...) penned the
words:

> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
> 
> IMO the main advantage of WebWork is that it's very easy to understand even
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
> 
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
> 
> What do you think about this ?
> 
> Regards,
> Lars
> 
>>> Do you not think that configuring some of this peripheral
>>> data should be at the view level?  If not the view, then
>>> where..? In common scenarios I come across, the secondary
>>> model is quite specific to a view (though not of course the
>>> TYPE of view)
>> 
>>> From what I've seen there's three commons scenerio's
>> 
>> 1. Reference data needed to render the view. This is the stuff we have
>> already.
>> 2. Data related to the view but not necessarily needed to render it
>> (additional news in a sidebox, perhaps a menu).
>> 3. Componentized views having corresponding controller (portlet)
>> 
>> The first case can perfectly be implemented using our current reference
>> data implementation (a list of elements in a select box of a form for
>> instance). One controller, having reference data, specifically belonging
>> to the controller
>> 
>> The second case (sideboxes containing news, a menu that needs
>> information not related to the main view) I consider to be a simple
>> Tiles approach and I think a somewhat more advanced version of the
>> reference data features we have now, would do. Something like you
>> proposed maybe. Reference data, however, not in fact related to the
>> controller!
>> 
>> The third case however, is a completely different one and somewhat looks
>> like the portlet approach. I think this is a bit too far-fetched to
>> implement in Spring, although I'd like to offer view-tech independent
>> stuff for this. Parallel controllers rendering views independent of
>> eachother.
>> 
>> It's just some rambling, but maybe we could brainstorm about this more
>> in order to come with something brilliant :)...
>> 
>> Alef
>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email sponsored by: ApacheCon 2003,
>> 16-19 November in Las Vegas. Learn firsthand the latest
>> developments in Apache, PHP, Perl, XML, Java, MySQL,
>> WebDAV, and more! http://www.apachecon.com/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer