Re: [Springframework-developer] Request and Session attributes in template based views

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

Darren,
=20
While I do agree with the argument that a Controller should be solely =
responsible for the exposed model, I see that there are valid exceptions =
to this rule. I wouldn't mind "exposeRequestAttributes", =
"exposeSessionAttributes" and possibly also =
"exposeServletContextAttributes" properties on an AbstractTemplateView =
base class, as long as they are turned off by default. As those flags =
are trivial to add, we could already do this for 1.0.2. What do others =
think?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Fr 07.05.2004 10:26
An: spr...@li...
Betreff: [Springframework-developer] Request and Session attributes in =
template based views




A project of mine uses a servlet Filter to pre-process many http =
requests,
as a result of which objects are occasionally added to the user's
HttpSession or as request attributes.

I need these objects to be available in some views, regardless of which
controller eventually handled the request.  That's OK for JSP/JSTL and
even Spring's XSLT and Document based views that have access to them, =
but
awkward for Velocity/FreeMarker.  It's not difficult to extend these =
views
to cope, but I wondered if it would be better as an addition to the
framework classes.

Two new bean properties would exist on VelocityView (also applies to
FreeMarkerView so possibly in a new AbstractTemplateView below
AbstractUrlBasedView)...

private boolean exposeRequestAttributes =3D false;
private boolean exposeSessionAttributes =3D false;
// corresponding public mutators omitted

The rendering methods can then use these properties to decide whether to
put request/session objects into the velocityContext or FreeMarker =
model.

There's obviously a good argument that says the controller is solely
responsible for deciding what ends up in the model, but the following
issues arise in that case:
  i. If a view currently takes advantage of having access to the
request/session, then switching view technologies to a template view is
impossible without amending controller code or specifying a
HandlerInterceptor to expose the same objects.
  ii. If a HandlerInterceptor is not used (potentially awkward to
configure)  then all controllers would potentially have to be modified
to cater for the requirement.  A common app-specific superclass would be
impossible if the behaviour was required from both FormControllers and
SimpleControllers

Thoughts?


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


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer