Re: [Springframework-developer] VelocityView

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

I've thought about this for quite a while from various angles, and have =
come 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 =
things, please override VelocityView's "exposeHelpers" method and expose =
formatter objects in just the way you need them.
=20
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 =
DateTool subclass that is aware of Spring's locale.
=20
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 =
soon 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" =
helpers that they develop instead of creating our ownl
=20
I've also revised VelocityEngineFactory and VelocityConfigurer in one =
specific point: Although I've introduced the "appRootMarker" mechanism =
there 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 Log4J but not really for a context-managed bean. Thus, I've =
replaced it with a "resourceLoaderPath" bean property on =
VelocityEngineFactory: Specifying this will automatically set the =
corresponding Velocity property "file.resource.loader.path" with the =
given path appended to the ApplicationContext's resource base.
=20
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:
=20
 <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 than 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.
=20
Juergen
=20

________________________________

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 =
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


-------------------------------------------------------
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