Menu
▾
▴
RE: [Springframework-developer] Final preparations for 1.1 RC1
|
From: Matt R. <li...@ra...> - 2004-07-24 00:09:45
|
I tried this out today and it works well. The only thing I saw that might cause confusion for users is there are 2 macros for Velocity (#springBind and #springBindEscaped) - whereas FreeMarker has one w/ an "escape" parameter. I imagine that folks using FreeMarker might be migrating from Velocity, so making the macros consistent might be helpful. Who knows - just a thought. I would make sure and document that the name "springMacroRequestContext" can be overridden by specifying a "requestContextAttribute" property. It's much easier to write $rc.getMessage() than $springMacroRequestContext.getMessage(). ;-) Matt > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of j=FCrgen h=F6ller [werk3AT] > Sent: Friday, July 23, 2004 12:30 AM > To: spr...@li... > Subject: Re: [Springframework-developer] Final preparations=20 > for 1.1 RC1 >=20 >=20 > After giving it some more thought, I've just replaced the=20 > Velocity/FreeMarkerFormView subclasses with a=20 > "exposeSpringMacroHelpers" property in AbstractTemplateView,=20 > inherited by VelocityView and FreeMarkerView. This triggers=20 > the exposure of a RequestContext instance under the name=20 > "springMacroRequestContext", as expected by the macros in=20 > spring.vm and spring.ftl now. > =20 > There's a new AbstractTemplateViewResolver that provided=20 > "exposeRequestAttributes", "exposeSessionAttributes" and=20 > "exposeSpringMacroHelpers" for all views. I've also added a=20 > FreeMarkerViewResolver as convenience subclass, as recently=20 > suggested by Matt Raible. > =20 > I've used the term "Spring macros" rather than "form macros"=20 > or "bind macros", to allow for adding further default macros=20 > that do not necessarily focus on binding data for forms. > =20 > If there aren't any objections, I'm about to commit these=20 > changes, as I believe they are worth it. Darren, what do you=20 > think? Do you maybe have the chance to adapt the docs accordingly? > =20 > Juergen > =20 >=20 > ________________________________ >=20 > Von: spr...@li... im=20 > Auftrag von j=FCrgen h=F6ller [werk3AT] > Gesendet: Do 22.07.2004 17:44 > An: spr...@li... > Betreff: Re: [Springframework-developer] Final preparations=20 > for 1.1 RC1 >=20 >=20 >=20 > Darren, >=20 > I've just moved BindStatus and reworked the configuration=20 > part a bit. I've also removed BindStatusHelper and moved its=20 > createBindStatus methods to the RequestContext class itself.=20 > VelocityFormView and FreeMarkerFormView simply expose a=20 > RequestContext instance under the name=20 > "bindStatusRequestContext" now, accessed by the macros in=20 > spring.vm respectively spring.ftl. >=20 > Regarding template loading, I've refined this a bit too: >=20 > * FreeMarkerConfigurer always registers an additional=20 > ClassTemplateLoader now, being able to load macros from the=20 > web.servlet.view.freemarker package. This means that a=20 > FreeMarker template can simply import "spring.ftl" now,=20 > rather than the lengthy=20 > "org/springframework/web/servlet/view/freemarker/spring.ftl". >=20 > * VelocityConfigurer always registers an additional=20 > ClasspathResourceLoader with the name "springFormMacro", plus=20 > the library "spring.vm" in the web.servlet.view.velocity=20 > package. Previously, the SpringResourceLoader was in=20 > potential conflict with a SpringResourceLoader from=20 > VelocityEngineFactory of the same name. Now, this should work=20 > with any kind and any number of primary resource loaders, as=20 > long as none is called "springFormMacro". >=20 > What I'm still wondering is whether we need the subclasses=20 > VelocityFormView and FreeMarkerFormView at all: They just=20 > expose a RequestContext instance under a special name now. We=20 > could easily move that logic into VelocityView respectively=20 > FreeMarkerView itself, driven by a "enableBindMacros" flag. >=20 > If the "enableBindMacros" flag existed on=20 > VelocityViewResolver and FreeMarkerViewResolver (to be=20 > created) too, it could be easily driven for all views. And=20 > there wouldn't be a need to override the viewClass property=20 > in that case. I'd prefer this over using view subclasses, as=20 > far as I can see. >=20 > What do you think? >=20 > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im=20 > Auftrag von Darren Davison > Gesendet: Mo 19.07.2004 12:33 > An: spr...@li... > Betreff: Re: [Springframework-developer] Final preparations=20 > for 1.1 RC1 >=20 >=20 >=20 >=20 >=20 > > - I'd like to move BindStatus and the new BindStatusHelper=20 > class from=20 > > servlet.tags to servlet.support. JSPs using the BindTag=20 > should still=20 > > work, provided that they get freshly compiled. Any=20 > objections to this? >=20 > I meant to raise this when I generalised the behaviour of=20 > them but it slipped my mind. They should be moved to a=20 > non-tag specific package now. >=20 > > - I'd like to refine resource loading in VelocityFormView and > > FreeMarkerFormView: This is not entirely clean when combined with=20 > > custom resource paths yet, from a superficial glance. >=20 > VelocityConfigurer (and respective FreeMarkerConfigurer)=20 > ensure a SpringResourceLoader is available for use, possibly=20 > in addition to any other resource loading strategy in the=20 > case of FreeMarker. Does this not cover requirements? I'm a=20 > little unclear on what's missing here.. >=20 > > Finally, regarding form simplification macros, i.e.=20 > Struts-style HTML=20 > > input tag wrappers: Do we already have something here, for=20 > either JSP=20 > > 2.0, Velocity or FreeMarker? >=20 > not from my side - personal events have overtaken me a little=20 > recently. I'd intended contacting Seth again to catch up on=20 > this and ensure a consistent approach for the three=20 > technologies. My feeling is that it should be fairly quick=20 > to add given the basic framework code is OK for resource=20 > loading, but I've not really looked closely at it yet. >=20 > Regards, > -- > Darren Davison > Public Key: http://www.davison.uk.net/pages/key.htm >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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.=20 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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=CCk _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
