Re: [Springframework-developer] Final preparations for 1.1 RC1

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

Darren,
=20
I've just moved BindStatus and reworked the configuration part a bit. =
I've also removed BindStatusHelper and moved its createBindStatus =
methods to the RequestContext class itself. VelocityFormView and =
FreeMarkerFormView simply expose a RequestContext instance under the =
name "bindStatusRequestContext" now, accessed by the macros in spring.vm =
respectively spring.ftl.
=20
Regarding template loading, I've refined this a bit too:
=20
* FreeMarkerConfigurer always registers an additional =
ClassTemplateLoader now, being able to load macros from the =
web.servlet.view.freemarker package. This means that a FreeMarker =
template can simply import "spring.ftl" now, rather than the lengthy =
"org/springframework/web/servlet/view/freemarker/spring.ftl".
=20
* VelocityConfigurer always registers an additional =
ClasspathResourceLoader with the name "springFormMacro", plus the =
library "spring.vm" in the web.servlet.view.velocity package. =
Previously, the SpringResourceLoader was in potential conflict with a =
SpringResourceLoader from VelocityEngineFactory of the same name. Now, =
this should work with any kind and any number of primary resource =
loaders, as long as none is called "springFormMacro".
=20
What I'm still wondering is whether we need the subclasses =
VelocityFormView and FreeMarkerFormView at all: They just expose a =
RequestContext instance under a special name now. We could easily move =
that logic into VelocityView respectively FreeMarkerView itself, driven =
by a "enableBindMacros" flag.
=20
If the "enableBindMacros" flag existed on VelocityViewResolver and =
FreeMarkerViewResolver (to be created) too, it could be easily driven =
for all views. And there wouldn't be a need to override the viewClass =
property in that case. I'd prefer this over using view subclasses, as =
far as I can see.
=20
What do you think?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Mo 19.07.2004 12:33
An: spr...@li...
Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1





> - I'd like to move BindStatus and the new BindStatusHelper class from
> servlet.tags to servlet.support. JSPs using the BindTag should still =
work,
> provided that they get freshly compiled. Any objections to this?

I meant to raise this when I generalised the behaviour of them but it
slipped my mind.  They should be moved to a non-tag specific package =
now.

> - I'd like to refine resource loading in VelocityFormView and
> FreeMarkerFormView: This is not entirely clean when combined with =
custom
> resource paths yet, from a superficial glance.

VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a
SpringResourceLoader is available for use, possibly in addition to any
other resource loading strategy in the case of FreeMarker.  Does this =
not
cover requirements?  I'm a little unclear on what's missing here..

> Finally, regarding form simplification macros, i.e. Struts-style HTML
> input tag wrappers: Do we already have something here, for either JSP =
2.0,
> Velocity or FreeMarker?

not from my side - personal events have overtaken me a little recently.
I'd intended contacting Seth again to catch up on this and ensure a
consistent approach for the three technologies.  My feeling is that it
should be fairly quick to add given the basic framework code is OK for
resource loading, but I've not really looked closely at it yet.

Regards,
--
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer