springframework-developer

[Springframework-developer] VelocityView

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

Everybody,

I'm not really happy with the helpers that VelocityView can expose. The =
fixed naming "simpleDateFormat" and "currencyFormat" seems arbitrary and =
is not in line with the way that AbstractView handles RequestContext =
exposure. The latter defines a "requestContextAttribute" property that =
can be set to the name that the RequestContext model attribute should =
have, if any.

Similarly, VelocityView could have "dateFormatAttribute" and =
"currencyFormatAttribute" properties to allow for specifying the names =
of those attributes, instead of fixed names and boolean =
"exposeDateFormatter" respectively "exposeCurrencyFormatter" flags. We =
could also add an additional "numberFormatAttribute" property, for a =
plain NumberFormat instance.

Alternatively, we could also scrap the helper exposure altogether and =
leave that to subclasses, or find some way to associate such model =
objects as static attributes - maybe via AbstractView's "attributesMap" =
that can take bean references too? The latter would involve setting up =
DateFormat and NumberFormat instances as beans, linking them in as model =
attributes via bean references.

After all, Velocity should really support such formatting itself - it is =
really weak in that respect. The JSTL's "fmt" tag library does that in a =
nice way for JSPs... Why does it have to be so complicated with =
Velocity? Finally, how are VelocityView users doing this currently? Is =
anyone using our exposure of pre-defined helpers or do you use your own =
mechanisms?

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] VelocityView

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there any reason that all of the VelocityView.mergeTemplate(...) method=
=20
can't be replaced with:

template.merge(context, response.getWriter());

Certainly works well here from what I've been able to see, but I'm not=20
entirely sure of the implications.  In particular I don't understand why=20
the VelocityServlet (which this code in mergeTemplate is from) authors=20
chose to do it the way they did.  Perhaps it's legacy code that's just=20
never been revisited, or there's some enormous performance benefit from=20
modifying the output buffer size or using VelocityWriter..?

Also, in VelocityEngineUtils.mergeTemplate(...) a new VelocityContext is=20
created from the model Map without verifying that model names are Velocity=
=20
compliant (no periods(.)).  VelocityView does this.  Suggest moving the=20
relevant method from VelocityView to VelocityEngineUtils, making it static=
=20
and having both classes call it.

I've already got these changes locally so can commit them if there's no=20
objection.  There's no impact on API, the existing test suite continues to=
=20
pass and I've checked a couple of existing Velocity projects with it.

Regards,
=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFARTo/KLMLAN01aw0RArI1AKCh6KkQEUtmDSbd+H6YRZ7IrDoRAwCdGuwj
wLF4sHO27a+97tJyroyXc3I=3D
=3D3jy4
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] VelocityView

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

> Similarly, VelocityView could have "dateFormatAttribute" and 
> "currencyFormatAttribute" properties to allow for specifying the 
> names of those attributes, instead of fixed names and boolean 
> "exposeDateFormatter" respectively "exposeCurrencyFormatter" flags. 
> We could also add an additional "numberFormatAttribute" property,
>  for a plain NumberFormat instance.
> 
> Alternatively, we could also scrap the helper exposure altogether 
> and leave that to subclasses, or find some way to associate such 
> model objects as static attributes - maybe via AbstractView's 
> "attributesMap" that can take bean references too? The latter would 
> involve setting up DateFormat and NumberFormat instances as beans, 
> linking them in as model attributes via bean references.
> 
> After all, Velocity should really support such formatting itself - 
> it is really weak in that respect. The JSTL's "fmt" tag library does 
> that in a nice way for JSPs... Why does it have to be so complicated 
> with Velocity? Finally, how are VelocityView users doing this 
> currently? Is anyone using our exposure of pre-defined helpers or do 
> you use your own mechanisms?

we're using the date format helper, simply because it was there - I'm not
particularly precious about it.  Supplying the helpers as beans defined in a
context seems the more 'Spring-centric' way to go, however the helpers
currently use static factory methods that take a locale parameter from the
current request - can that still be handled?

As long as there's no loss of functionality, I'm +1 for anything!



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