Re: [Springframework-developer] VelocityView

[Rod J. <rod...@in...>]

+1. I did actually consider using a velocity package for this, but there =
was
no download of that back when I wrote the first version of the Velocity
support last year.

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>;
<spr...@li...>
Sent: Saturday, December 13, 2003 12:30 AM
Subject: Re: [Springframework-developer] VelocityView


I've thought about this for quite a while from various angles, and have c=
ome
to the conclusion that no such exposing of pre-defined DateFormats or
NumberFormats will be flexible enough: There are simply too many options =
to
generate instances, with DateFormat.LONG/SHORT,
getNumberInstance/getPercentInstance, etc. Any choice of pre-defined
formatters will be arbitrary. Thus, I've removed the whole DateFormat and
NumberFormat support from VelocityView. Whoever needs to expose such thin=
gs,
please override VelocityView's "exposeHelpers" method and expose formatte=
r
objects in just the way you need them.

As an alternative, I've integrated support for Velocity Tools, the extra
download from the Velocity team offered since this summer. Velocity Tools
features a "DateTool" class that is exactly targetted at our use case:
formatting dates in Velocity templates. Our VelocityView has a
"dateToolAttribute" property now, taking the name under which to expose a
DateTool instance, if desired. VelocityView will actually expose a DateTo=
ol
subclass that is aware of Spring's locale.

In the current Velocity Tools 1.1 dev version, they've introduced an
analogous "NumberTool" class, supporting all kinds of number formatting
options. I intend to support that too via a "numberToolAttribute", as soo=
n
as it's released in a beta. If something's missing, we should tell the
Velocity Tools team: I consider it preferable to use the "official" helpe=
rs
that they develop instead of creating our ownl

I've also revised VelocityEngineFactory and VelocityConfigurer in one
specific point: Although I've introduced the "appRootMarker" mechanism th=
ere
myself to allow for a resource loader path relative to the application
context, I've never been happy with it. That mechanism is suitable for Lo=
g4J
but not really for a context-managed bean. Thus, I've replaced it with a
"resourceLoaderPath" bean property on VelocityEngineFactory: Specifying t=
his
will automatically set the corresponding Velocity property
"file.resource.loader.path" with the given path appended to the
ApplicationContext's resource base.

Setting up a VelocityConfigurer for typical web usage is now even simpler
than before, as you just need to specify a "resourceLoaderPath", and just
optionally some other Velocity properties:

 <bean id=3D"velocityConfig"
class=3D"org.springframework.web.servlet.view.velocity.VelocityConfigurer=
">
  <property
name=3D"resourceLoaderPath"><value>/WEB-INF/velocity/</value></property>
 </bean>

Darren, and of course other Spring/Velocity users, could you please give =
the
reworked stuff a try before the 1.0 M4 release? I consider it cleaner tha=
n
before -- after all, we will need to support what we release as 1.0 final
for quite some time to come --, so I hope that you don't mind the changes.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Darren Davison
Gesendet: Fr 12.12.2003 10:07
An: spr...@li...
Betreff: Re: [Springframework-developer] VelocityView




> 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 i=
n a
context seems the more 'Spring-centric' way to go, however the helpers
currently use static factory methods that take a locale parameter from th=
e
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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer