Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-23 06:27:38
|
After giving it some more thought, I've just replaced the = Velocity/FreeMarkerFormView subclasses with a "exposeSpringMacroHelpers" = property in AbstractTemplateView, inherited by VelocityView and = FreeMarkerView. This triggers the exposure of a RequestContext instance = under the name "springMacroRequestContext", as expected by the macros in = spring.vm and spring.ftl now. =20 There's a new AbstractTemplateViewResolver that provided = "exposeRequestAttributes", "exposeSessionAttributes" and = "exposeSpringMacroHelpers" for all views. I've also added a = FreeMarkerViewResolver as convenience subclass, as recently suggested by = Matt Raible. =20 I've used the term "Spring macros" rather than "form macros" or "bind = macros", to allow for adding further default macros that do not = necessarily focus on binding data for forms. =20 If there aren't any objections, I'm about to commit these changes, as I = believe they are worth it. Darren, what do you think? Do you maybe have = the chance to adapt the docs accordingly? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Do 22.07.2004 17:44 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 Darren, 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. Regarding template loading, I've refined this a bit too: * 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". * 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". 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. 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. What do you think? Juergen ________________________________ 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 ------------------------------------------------------- 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 |
|
From: Darren D. <da...@da...> - 2004-07-23 07:35:09
|
> After giving it some more thought, I've just replaced the > Velocity/FreeMarkerFormView subclasses with a "exposeSpringMacroHelpers= " > property in AbstractTemplateView, inherited by VelocityView and > FreeMarkerView. This triggers the exposure of a RequestContext instance > under the name "springMacroRequestContext", as expected by the macros i= n > spring.vm and spring.ftl now. > > There's a new AbstractTemplateViewResolver that provided > "exposeRequestAttributes", "exposeSessionAttributes" and > "exposeSpringMacroHelpers" for all views. I've also added a > FreeMarkerViewResolver as convenience subclass, as recently suggested b= y > Matt Raible. > > I've used the term "Spring macros" rather than "form macros" or "bind > macros", to allow for adding further default macros that do not > necessarily focus on binding data for forms. > > If there aren't any objections, I'm about to commit these changes, as I > believe they are worth it. Darren, what do you think? Do you maybe have > the chance to adapt the docs accordingly? sounds great Juergen - sorry didn't get a chance to look at this and respond last night, the beer fairy seduced me ;-) I'll take a look tonight and update ref docs. When's RC1 going to be released - Sunday? --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |
|
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 |
|
From: Darren D. <da...@da...> - 2004-07-24 08:18:20
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 01:09, Matt Raible wrote: > 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. =46reeMarker has a default value of false for the 2nd param so you only nee= d=20 supply it to override it. Velocity can't do that. The other options for Velocity are: * always supply the second parameter in every call to springBind * use a globally scoped, well-known variable defined in user templates. I prefer personally to always require the additional parameter. It's more= =20 consistent with FM and won't cause user templates to break if they migrate= =20 them to FM using the automatic conversion tool they have available. What do you think? > 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(). ;-) I will, thanks. =2D --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq cn71Z/8ovFjaDLQRxtBwTfo=3D =3Dlvg2 =2D----END PGP SIGNATURE----- |
|
From: Shishir K. S. <sk...@sy...> - 2004-07-23 09:28:57
|
Juergen,=20 Will the Jira issue SPR-214 (is this is a bug at all ) be resolved in 1.1 RC1 Thanks Shishir =20 |
|
From: <jue...@we...> - 2004-07-24 13:11:10
|
Darren, =20 Oops, I forgot to discuss that one: The reason why I removed the = htmlEscape property from the "springBind" macro is to be able to = participate in a RequestContext-level default, e.g. set via = springMacroRequestContext.setDefaultHtmlEscape(true). Note that the = createBindStatus invocation on RequestContext uses the defaultHtmlEscape = flag then. =20 I've just adapted the RequestContext implementation a bit further to = also be able to participate in a ServletContext-level default, just like = our JSP tags can, i.e. a "defaultHtmlEscape" context-param in web.xml. = JSP tags and Velocity/FreeMarker macros can then even share such an = application-wide default. I'll commit this promptly. =20 Actually, the "springBindEscaped" macro should rather take an explicit = htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue to = false for a specific macro. Hmm, what name could we use for this? = "springBindWithExplicitEscape" is clearly too long... "springBind" with = overloaded signature is not possible in Velocity... maybe still = "springBindEscaped", but just with an explicit parameter? =20 =20 Matt, =20 Note that the "springMacroRequestContext" is not really meant to be = accessed directly; it is mainly meant to be used by Spring-provided = macros. If you want to use a RequestContext in your own expressions, = always specify the "requestContextAttribute" accordingly. We should = highlight that in the docs. =20 =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Darren Davison Gesendet: Sa 24.07.2004 10:18 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 01:09, Matt Raible wrote: > 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. FreeMarker has a default value of false for the 2nd param so you only = need supply it to override it. Velocity can't do that. The other options for Velocity are: * always supply the second parameter in every call to springBind * use a globally scoped, well-known variable defined in user templates. I prefer personally to always require the additional parameter. It's = more consistent with FM and won't cause user templates to break if they = migrate them to FM using the automatic conversion tool they have available. What do you think? > 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(). ;-) I will, thanks. - -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq cn71Z/8ovFjaDLQRxtBwTfo=3D =3Dlvg2 -----END PGP SIGNATURE----- ------------------------------------------------------- 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 |
|
From: Seth L. <set...@gm...> - 2004-07-24 18:42:53
|
On Sat, 24 Jul 2004 15:12:53 +0200, j=FCrgen h=F6ller [werk3AT] <jue...@we...> wrote: > Darren, >=20 > Oops, I forgot to discuss that one: The reason why I removed the htmlEsca= pe property from the "springBind" macro is to be able to participate in a R= equestContext-level default, e.g. set via springMacroRequestContext.setDefa= ultHtmlEscape(true). Note that the createBindStatus invocation on RequestCo= ntext uses the defaultHtmlEscape flag then. >=20 > I've just adapted the RequestContext implementation a bit further to also= be able to participate in a ServletContext-level default, just like our JS= P tags can, i.e. a "defaultHtmlEscape" context-param in web.xml. JSP tags a= nd Velocity/FreeMarker macros can then even share such an application-wide = default. I'll commit this promptly. >=20 Would it be appropriate to add a application-wide config param called 'usingDtd' with values such as 'XHTML1.0Strict" or "HTML4.01". This would help tags that do omit HTML to omit the proper markup. This would be useful for the convenience form macros. Thanks, Seth |
|
From: Matt R. <li...@ra...> - 2004-07-24 18:46:27
|
On Jul 24, 2004, at 7:12 AM, j=FCrgen h=F6ller [werk3AT] wrote: > Note that the "springMacroRequestContext" is not really meant to be=20 > accessed directly; it is mainly meant to be used by Spring-provided=20 > macros. If you want to use a RequestContext in your own expressions,=20= > always specify the "requestContextAttribute" accordingly. We should=20 > highlight that in the docs. > Right, but it actually does work if you use it. To me, setting the=20 requestContextAttribute value seems to simply provide an alias for it. =20= Is it doing more than that? >> I would make sure and document that the name=20 >> "springMacroRequestContext" >> can be overridden by specifying a "requestContextAttribute" property. >> It's much easier to write $rc.getMessage() than >> $springMacroRequestContext.getMessage(). ;-) > |
|
From: <jue...@we...> - 2004-07-24 16:17:08
|
Actually, the same issue occurs with FreeMarker too: We specify = "escape=3Dfalse" there, so do not participate in any default. This needs = to be addressed: We should allow to work with the defaultHtmlEscape = value here too. =20 While we could introduce a further "escape" value for "use default", = offering a special method signature for it, it's probably clearer two = offer two FreeMarker macros: "spring:bind" which never takes an "escape" = parameter (i.e. always uses the default), and "spring:bindEscaped" which = takes a required "escape" parameter. This would be analogous to Velocity = again then. =20 However, there's still the naming issue: "bind" uses the default HTML = escape setting. But how to the name the version that takes an explicit = HTML escape parameter? Is there a better name than "bindEscaped"? =20 This is easier with JSP tags, where there can be a true tag-internal = default if the "setHtmlEscape" method was not called... As far as I can = see, even FreeMarker just allows for an explicitly specified default in = the macro definition: It cannot seamlessly invoke either = RequestContext.createBindStatus(path) respectively = RequestContext.createBindStatus(path, htmlEscape), in our concrete case. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Sa 24.07.2004 15:12 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 Darren, Oops, I forgot to discuss that one: The reason why I removed the = htmlEscape property from the "springBind" macro is to be able to = participate in a RequestContext-level default, e.g. set via = springMacroRequestContext.setDefaultHtmlEscape(true). Note that the = createBindStatus invocation on RequestContext uses the defaultHtmlEscape = flag then. I've just adapted the RequestContext implementation a bit further to = also be able to participate in a ServletContext-level default, just like = our JSP tags can, i.e. a "defaultHtmlEscape" context-param in web.xml. = JSP tags and Velocity/FreeMarker macros can then even share such an = application-wide default. I'll commit this promptly. Actually, the "springBindEscaped" macro should rather take an explicit = htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue to = false for a specific macro. Hmm, what name could we use for this? = "springBindWithExplicitEscape" is clearly too long... "springBind" with = overloaded signature is not possible in Velocity... maybe still = "springBindEscaped", but just with an explicit parameter? Matt, Note that the "springMacroRequestContext" is not really meant to be = accessed directly; it is mainly meant to be used by Spring-provided = macros. If you want to use a RequestContext in your own expressions, = always specify the "requestContextAttribute" accordingly. We should = highlight that in the docs. Juergen ________________________________ Von: spr...@li... im Auftrag = von Darren Davison Gesendet: Sa 24.07.2004 10:18 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 01:09, Matt Raible wrote: > 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. FreeMarker has a default value of false for the 2nd param so you only = need supply it to override it. Velocity can't do that. The other options for Velocity are: * always supply the second parameter in every call to springBind * use a globally scoped, well-known variable defined in user templates. I prefer personally to always require the additional parameter. It's = more consistent with FM and won't cause user templates to break if they = migrate them to FM using the automatic conversion tool they have available. What do you think? > 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(). ;-) I will, thanks. - -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq cn71Z/8ovFjaDLQRxtBwTfo=3D =3Dlvg2 -----END PGP SIGNATURE----- ------------------------------------------------------- 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=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Matt R. <li...@ra...> - 2004-07-24 18:44:48
|
It would be nice if the method name didn't have to change and we could=20=
just control the rendering of the variable. Probably not possible, but=20=
something similar to JSP 2.0 where you use ${status.errorMessage} to=20
print out escaped XML and <c:out value=3D"${status.errorMessage}"=20
escapeXml=3D"false"/> if you want to print HTML.
I don't see a problem with having two separate methods: springBind and=20=
springBindEscaped - just as long as its documented. Though it might be=20=
nicer to have #springBind(path) and #springBind(path false) - where you=20=
have to use two parameters to escape XML.
Matt
On Jul 24, 2004, at 10:19 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> Actually, the same issue occurs with FreeMarker too: We specify=20
> "escape=3Dfalse" there, so do not participate in any default. This =
needs=20
> to be addressed: We should allow to work with the defaultHtmlEscape=20
> value here too.
>
> While we could introduce a further "escape" value for "use default",=20=
> offering a special method signature for it, it's probably clearer two=20=
> offer two FreeMarker macros: "spring:bind" which never takes an=20
> "escape" parameter (i.e. always uses the default), and=20
> "spring:bindEscaped" which takes a required "escape" parameter. This=20=
> would be analogous to Velocity again then.
>
> However, there's still the naming issue: "bind" uses the default HTML=20=
> escape setting. But how to the name the version that takes an explicit=20=
> HTML escape parameter? Is there a better name than "bindEscaped"?
>
> This is easier with JSP tags, where there can be a true tag-internal=20=
> default if the "setHtmlEscape" method was not called... As far as I=20
> can see, even FreeMarker just allows for an explicitly specified=20
> default in the macro definition: It cannot seamlessly invoke either=20
> RequestContext.createBindStatus(path) respectively=20
> RequestContext.createBindStatus(path, htmlEscape), in our concrete=20
> case.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20=
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Sa 24.07.2004 15:12
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> Darren,
>
> Oops, I forgot to discuss that one: The reason why I removed the=20
> htmlEscape property from the "springBind" macro is to be able to=20
> participate in a RequestContext-level default, e.g. set via=20
> springMacroRequestContext.setDefaultHtmlEscape(true). Note that the=20
> createBindStatus invocation on RequestContext uses the=20
> defaultHtmlEscape flag then.
>
> I've just adapted the RequestContext implementation a bit further to=20=
> also be able to participate in a ServletContext-level default, just=20
> like our JSP tags can, i.e. a "defaultHtmlEscape" context-param in=20
> web.xml. JSP tags and Velocity/FreeMarker macros can then even share=20=
> such an application-wide default. I'll commit this promptly.
>
> Actually, the "springBindEscaped" macro should rather take an explicit=20=
> htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue =
to=20
> false for a specific macro. Hmm, what name could we use for this?=20
> "springBindWithExplicitEscape" is clearly too long... "springBind"=20
> with overloaded signature is not possible in Velocity... maybe still=20=
> "springBindEscaped", but just with an explicit parameter?
>
>
> Matt,
>
> Note that the "springMacroRequestContext" is not really meant to be=20
> accessed directly; it is mainly meant to be used by Spring-provided=20
> macros. If you want to use a RequestContext in your own expressions,=20=
> always specify the "requestContextAttribute" accordingly. We should=20
> highlight that in the docs.
>
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20=
> von Darren Davison
> Gesendet: Sa 24.07.2004 10:18
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 24 July 2004 01:09, Matt Raible wrote:
>> 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/=20=
>> 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.
>
> FreeMarker has a default value of false for the 2nd param so you only=20=
> need
> supply it to override it. Velocity can't do that.
>
> The other options for Velocity are:
>
> * always supply the second parameter in every call to springBind
>
> * use a globally scoped, well-known variable defined in user=20
> templates.
>
>
> I prefer personally to always require the additional parameter. It's=20=
> more
> consistent with FM and won't cause user templates to break if they=20
> migrate
> them to FM using the automatic conversion tool they have available.
>
> What do you think?
>
>
>> I would make sure and document that the name=20
>> "springMacroRequestContext"
>> can be overridden by specifying a "requestContextAttribute" property.
>> It's much easier to write $rc.getMessage() than
>> $springMacroRequestContext.getMessage(). ;-)
>
> I will, thanks.
>
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq
> cn71Z/8ovFjaDLQRxtBwTfo=3D
> =3Dlvg2
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> 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=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
|
|
From: <jue...@we...> - 2004-07-24 19:29:27
|
As far I see, there is no such overloading of macros in Velocity: If we =
have different parameters, we need to define a separate macro.
=20
Even in FreeMarker, there's just the option to define a fixed default =
for optional parameters: no support for simply "not specified" (falling =
back to the default HTML escape setting in our case). That's why I =
suggest to use a different macro name there too, analogous to Velocity.
=20
So the remaining issue are the names: "springBind" (default HTML escape =
setting) and "springBindEscaped" (explicitly specified HTML escape =
setting)?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 24.07.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1
It would be nice if the method name didn't have to change and we could
just control the rendering of the variable. Probably not possible, but
something similar to JSP 2.0 where you use ${status.errorMessage} to
print out escaped XML and <c:out value=3D"${status.errorMessage}"
escapeXml=3D"false"/> if you want to print HTML.
I don't see a problem with having two separate methods: springBind and
springBindEscaped - just as long as its documented. Though it might be
nicer to have #springBind(path) and #springBind(path false) - where you
have to use two parameters to escape XML.
Matt
On Jul 24, 2004, at 10:19 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> Actually, the same issue occurs with FreeMarker too: We specify
> "escape=3Dfalse" there, so do not participate in any default. This =
needs
> to be addressed: We should allow to work with the defaultHtmlEscape
> value here too.
>
> While we could introduce a further "escape" value for "use default",
> offering a special method signature for it, it's probably clearer two
> offer two FreeMarker macros: "spring:bind" which never takes an
> "escape" parameter (i.e. always uses the default), and
> "spring:bindEscaped" which takes a required "escape" parameter. This
> would be analogous to Velocity again then.
>
> However, there's still the naming issue: "bind" uses the default HTML
> escape setting. But how to the name the version that takes an explicit
> HTML escape parameter? Is there a better name than "bindEscaped"?
>
> This is easier with JSP tags, where there can be a true tag-internal
> default if the "setHtmlEscape" method was not called... As far as I
> can see, even FreeMarker just allows for an explicitly specified
> default in the macro definition: It cannot seamlessly invoke either
> RequestContext.createBindStatus(path) respectively
> RequestContext.createBindStatus(path, htmlEscape), in our concrete
> case.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Sa 24.07.2004 15:12
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> Darren,
>
> Oops, I forgot to discuss that one: The reason why I removed the
> htmlEscape property from the "springBind" macro is to be able to
> participate in a RequestContext-level default, e.g. set via
> springMacroRequestContext.setDefaultHtmlEscape(true). Note that the
> createBindStatus invocation on RequestContext uses the
> defaultHtmlEscape flag then.
>
> I've just adapted the RequestContext implementation a bit further to
> also be able to participate in a ServletContext-level default, just
> like our JSP tags can, i.e. a "defaultHtmlEscape" context-param in
> web.xml. JSP tags and Velocity/FreeMarker macros can then even share
> such an application-wide default. I'll commit this promptly.
>
> Actually, the "springBindEscaped" macro should rather take an explicit
> htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue =
to
> false for a specific macro. Hmm, what name could we use for this?
> "springBindWithExplicitEscape" is clearly too long... "springBind"
> with overloaded signature is not possible in Velocity... maybe still
> "springBindEscaped", but just with an explicit parameter?
>
>
> Matt,
>
> Note that the "springMacroRequestContext" is not really meant to be
> accessed directly; it is mainly meant to be used by Spring-provided
> macros. If you want to use a RequestContext in your own expressions,
> always specify the "requestContextAttribute" accordingly. We should
> highlight that in the docs.
>
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Darren Davison
> Gesendet: Sa 24.07.2004 10:18
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 24 July 2004 01:09, Matt Raible wrote:
>> 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.
>
> FreeMarker has a default value of false for the 2nd param so you only
> need
> supply it to override it. Velocity can't do that.
>
> The other options for Velocity are:
>
> * always supply the second parameter in every call to springBind
>
> * use a globally scoped, well-known variable defined in user
> templates.
>
>
> I prefer personally to always require the additional parameter. It's
> more
> consistent with FM and won't cause user templates to break if they
> migrate
> them to FM using the automatic conversion tool they have available.
>
> What do you think?
>
>
>> 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(). ;-)
>
> I will, thanks.
>
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq
> cn71Z/8ovFjaDLQRxtBwTfo=3D
> =3Dlvg2
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> 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=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
-------------------------------------------------------
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
|
|
From: Matt R. <li...@ra...> - 2004-07-24 19:53:13
|
On Jul 24, 2004, at 1:28 PM, j=FCrgen h=F6ller [werk3AT] wrote: > > So the remaining issue are the names: "springBind" (default HTML=20 > escape setting) and "springBindEscaped" (explicitly specified HTML=20 > escape setting)? Using these names sounds good to me. Matt |
|
From: Rob H. <ro...@ca...> - 2004-07-25 19:58:14
|
This can be achieved using custom directives in Velocity, i.e you can =
have a
varied number of parameters and you can specify defaults for each one. =
The
only drawback is that directives have to be coded in Java and are not =
quite
as easy to build as macros since you have to interact directly with the =
AST
constructed by the parser.
Rob
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 24 July 2004 20:29
To: spr...@li...
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1
As far I see, there is no such overloading of macros in Velocity: If we =
have
different parameters, we need to define a separate macro.
=20
Even in FreeMarker, there's just the option to define a fixed default =
for
optional parameters: no support for simply "not specified" (falling back =
to
the default HTML escape setting in our case). That's why I suggest to =
use a
different macro name there too, analogous to Velocity.
=20
So the remaining issue are the names: "springBind" (default HTML escape
setting) and "springBindEscaped" (explicitly specified HTML escape =
setting)?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von
Matt Raible
Gesendet: Sa 24.07.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1
It would be nice if the method name didn't have to change and we could
just control the rendering of the variable. Probably not possible, but
something similar to JSP 2.0 where you use ${status.errorMessage} to
print out escaped XML and <c:out value=3D"${status.errorMessage}"
escapeXml=3D"false"/> if you want to print HTML.
I don't see a problem with having two separate methods: springBind and
springBindEscaped - just as long as its documented. Though it might be
nicer to have #springBind(path) and #springBind(path false) - where you
have to use two parameters to escape XML.
Matt
On Jul 24, 2004, at 10:19 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> Actually, the same issue occurs with FreeMarker too: We specify
> "escape=3Dfalse" there, so do not participate in any default. This =
needs
> to be addressed: We should allow to work with the defaultHtmlEscape
> value here too.
>
> While we could introduce a further "escape" value for "use default",
> offering a special method signature for it, it's probably clearer two
> offer two FreeMarker macros: "spring:bind" which never takes an
> "escape" parameter (i.e. always uses the default), and
> "spring:bindEscaped" which takes a required "escape" parameter. This
> would be analogous to Velocity again then.
>
> However, there's still the naming issue: "bind" uses the default HTML
> escape setting. But how to the name the version that takes an explicit
> HTML escape parameter? Is there a better name than "bindEscaped"?
>
> This is easier with JSP tags, where there can be a true tag-internal
> default if the "setHtmlEscape" method was not called... As far as I
> can see, even FreeMarker just allows for an explicitly specified
> default in the macro definition: It cannot seamlessly invoke either
> RequestContext.createBindStatus(path) respectively
> RequestContext.createBindStatus(path, htmlEscape), in our concrete
> case.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Sa 24.07.2004 15:12
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> Darren,
>
> Oops, I forgot to discuss that one: The reason why I removed the
> htmlEscape property from the "springBind" macro is to be able to
> participate in a RequestContext-level default, e.g. set via
> springMacroRequestContext.setDefaultHtmlEscape(true). Note that the
> createBindStatus invocation on RequestContext uses the
> defaultHtmlEscape flag then.
>
> I've just adapted the RequestContext implementation a bit further to
> also be able to participate in a ServletContext-level default, just
> like our JSP tags can, i.e. a "defaultHtmlEscape" context-param in
> web.xml. JSP tags and Velocity/FreeMarker macros can then even share
> such an application-wide default. I'll commit this promptly.
>
> Actually, the "springBindEscaped" macro should rather take an explicit
> htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue =
to
> false for a specific macro. Hmm, what name could we use for this?
> "springBindWithExplicitEscape" is clearly too long... "springBind"
> with overloaded signature is not possible in Velocity... maybe still
> "springBindEscaped", but just with an explicit parameter?
>
>
> Matt,
>
> Note that the "springMacroRequestContext" is not really meant to be
> accessed directly; it is mainly meant to be used by Spring-provided
> macros. If you want to use a RequestContext in your own expressions,
> always specify the "requestContextAttribute" accordingly. We should
> highlight that in the docs.
>
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Darren Davison
> Gesendet: Sa 24.07.2004 10:18
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 24 July 2004 01:09, Matt Raible wrote:
>> 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.
>
> FreeMarker has a default value of false for the 2nd param so you only
> need
> supply it to override it. Velocity can't do that.
>
> The other options for Velocity are:
>
> * always supply the second parameter in every call to springBind
>
> * use a globally scoped, well-known variable defined in user
> templates.
>
>
> I prefer personally to always require the additional parameter. It's
> more
> consistent with FM and won't cause user templates to break if they
> migrate
> them to FM using the automatic conversion tool they have available.
>
> What do you think?
>
>
>> 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(). ;-)
>
> I will, thanks.
>
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq
> cn71Z/8ovFjaDLQRxtBwTfo=3D
> =3Dlvg2
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> 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=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
-------------------------------------------------------
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-07-24 19:31:26
|
Sure - I still recommend to specify a brief "requestContextAttribute" = name like "rc" for custom usage, though. =20 The "springMacroRequestContext" should rather be considered an = implementation detail of the Spring-provided macros, to be activated by = the "exposeSpringMacroHelpers" flag. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Matt Raible Gesendet: Sa 24.07.2004 20:46 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 On Jul 24, 2004, at 7:12 AM, j=FCrgen h=F6ller [werk3AT] wrote: > Note that the "springMacroRequestContext" is not really meant to be > accessed directly; it is mainly meant to be used by Spring-provided > macros. If you want to use a RequestContext in your own expressions, > always specify the "requestContextAttribute" accordingly. We should > highlight that in the docs. > Right, but it actually does work if you use it. To me, setting the requestContextAttribute value seems to simply provide an alias for it.=20 Is it doing more than that? >> 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(). ;-) > ------------------------------------------------------- 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 |
|
From: Matt R. <li...@ra...> - 2004-07-26 16:30:09
|
> -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of Darren Davison > Sent: Saturday, July 24, 2004 2:11 AM >=20 > On Saturday 24 July 2004 01:13, Matt Raible wrote: >=20 > > FYI... > > > > This doesn't work: > > > > <#import "spring.ftl" as spring /> >=20 > hmm.. it works ok for me. I just tried a build from last night and I still get the same behavior. My FreeMarker templates are in WEB-INF/freemarker, my "templateLoaderPath" (on FreeMarkerConfigurer) is "/". Here is the error I get: WEB-INF/freemarker/spring.ftl javax.servlet.ServletException: Error reading imported file WEB-INF/freemarker/spring.ftl at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServle t.java:338) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Matt >=20 > > But this does: > > > > <#import "/spring.ftl" as spring /> > > > > Just thought it should be documented. >=20 > - --=20 > Darren Davison > Public Key: http://www.davison.uk.net/pages/key.htm > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) >=20 > iD8DBQFBAhmMKLMLAN01aw0RAuNlAKCJkf8+pnwIP4Bt31VwninHric7jgCeIA7v > w/4rPbU0TC06WZLKkIzVczw=3D > =3DWfZk > -----END PGP SIGNATURE----- >=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=CCk _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-07-27 10:39:04
|
Darren, any thoughts on the current macros, particularly regarding the =
"springBind" and "springBindEscaped" naming? See the discussion in the =
mails below.
=20
It's already somewhat urgent, as I'd like to release 1.1 RC1 tonight :-)
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 24.07.2004 21:28
An: spr...@li...
Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1
As far I see, there is no such overloading of macros in Velocity: If we =
have different parameters, we need to define a separate macro.
Even in FreeMarker, there's just the option to define a fixed default =
for optional parameters: no support for simply "not specified" (falling =
back to the default HTML escape setting in our case). That's why I =
suggest to use a different macro name there too, analogous to Velocity.
So the remaining issue are the names: "springBind" (default HTML escape =
setting) and "springBindEscaped" (explicitly specified HTML escape =
setting)?
Juergen
________________________________
Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 24.07.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1
It would be nice if the method name didn't have to change and we could
just control the rendering of the variable. Probably not possible, but
something similar to JSP 2.0 where you use ${status.errorMessage} to
print out escaped XML and <c:out value=3D"${status.errorMessage}"
escapeXml=3D"false"/> if you want to print HTML.
I don't see a problem with having two separate methods: springBind and
springBindEscaped - just as long as its documented. Though it might be
nicer to have #springBind(path) and #springBind(path false) - where you
have to use two parameters to escape XML.
Matt
On Jul 24, 2004, at 10:19 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> Actually, the same issue occurs with FreeMarker too: We specify
> "escape=3Dfalse" there, so do not participate in any default. This =
needs
> to be addressed: We should allow to work with the defaultHtmlEscape
> value here too.
>
> While we could introduce a further "escape" value for "use default",
> offering a special method signature for it, it's probably clearer two
> offer two FreeMarker macros: "spring:bind" which never takes an
> "escape" parameter (i.e. always uses the default), and
> "spring:bindEscaped" which takes a required "escape" parameter. This
> would be analogous to Velocity again then.
>
> However, there's still the naming issue: "bind" uses the default HTML
> escape setting. But how to the name the version that takes an explicit
> HTML escape parameter? Is there a better name than "bindEscaped"?
>
> This is easier with JSP tags, where there can be a true tag-internal
> default if the "setHtmlEscape" method was not called... As far as I
> can see, even FreeMarker just allows for an explicitly specified
> default in the macro definition: It cannot seamlessly invoke either
> RequestContext.createBindStatus(path) respectively
> RequestContext.createBindStatus(path, htmlEscape), in our concrete
> case.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Sa 24.07.2004 15:12
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> Darren,
>
> Oops, I forgot to discuss that one: The reason why I removed the
> htmlEscape property from the "springBind" macro is to be able to
> participate in a RequestContext-level default, e.g. set via
> springMacroRequestContext.setDefaultHtmlEscape(true). Note that the
> createBindStatus invocation on RequestContext uses the
> defaultHtmlEscape flag then.
>
> I've just adapted the RequestContext implementation a bit further to
> also be able to participate in a ServletContext-level default, just
> like our JSP tags can, i.e. a "defaultHtmlEscape" context-param in
> web.xml. JSP tags and Velocity/FreeMarker macros can then even share
> such an application-wide default. I'll commit this promptly.
>
> Actually, the "springBindEscaped" macro should rather take an explicit
> htmlEscape parameter, to be able to override defaultHtmlEscape=3Dtrue =
to
> false for a specific macro. Hmm, what name could we use for this?
> "springBindWithExplicitEscape" is clearly too long... "springBind"
> with overloaded signature is not possible in Velocity... maybe still
> "springBindEscaped", but just with an explicit parameter?
>
>
> Matt,
>
> Note that the "springMacroRequestContext" is not really meant to be
> accessed directly; it is mainly meant to be used by Spring-provided
> macros. If you want to use a RequestContext in your own expressions,
> always specify the "requestContextAttribute" accordingly. We should
> highlight that in the docs.
>
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Darren Davison
> Gesendet: Sa 24.07.2004 10:18
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Final preparations for 1.1 =
RC1
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 24 July 2004 01:09, Matt Raible wrote:
>> 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.
>
> FreeMarker has a default value of false for the 2nd param so you only
> need
> supply it to override it. Velocity can't do that.
>
> The other options for Velocity are:
>
> * always supply the second parameter in every call to springBind
>
> * use a globally scoped, well-known variable defined in user
> templates.
>
>
> I prefer personally to always require the additional parameter. It's
> more
> consistent with FM and won't cause user templates to break if they
> migrate
> them to FM using the automatic conversion tool they have available.
>
> What do you think?
>
>
>> 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(). ;-)
>
> I will, thanks.
>
> - --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBAhtIKLMLAN01aw0RAisgAKCfjnl6dzgkdQ91o9lUrUvtd9RGWQCfRJNq
> cn71Z/8ovFjaDLQRxtBwTfo=3D
> =3Dlvg2
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> 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=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
-------------------------------------------------------
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Darren D. <da...@da...> - 2004-07-27 11:01:29
|
> Darren, any thoughts on the current macros, particularly regarding the > "springBind" and "springBindEscaped" naming? See the discussion in the > mails below. > > It's already somewhat urgent, as I'd like to release 1.1 RC1 tonight :-= ) Sorry, I thought it had been decided already :) I reckon we should go with what's in CVS now. Given Velocity's difficult= y with overloading, the need to be consistent as far as possible with FreeMarker and the need for both to respect the context parameter for default escaping, I can't think of any better way to organise or name them. The ref docs were modified and committed last night, so they're alredy consistent with what's currently in the macro files. Regards, --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |
|
From: <jue...@we...> - 2004-07-27 11:22:08
|
OK, thanks! :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Darren Davison Gesendet: Di 27.07.2004 13:01 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 > Darren, any thoughts on the current macros, particularly regarding the > "springBind" and "springBindEscaped" naming? See the discussion in the > mails below. > > It's already somewhat urgent, as I'd like to release 1.1 RC1 tonight = :-) Sorry, I thought it had been decided already :) I reckon we should go with what's in CVS now. Given Velocity's = difficulty with overloading, the need to be consistent as far as possible with FreeMarker and the need for both to respect the context parameter for default escaping, I can't think of any better way to organise or name them. The ref docs were modified and committed last night, so they're alredy consistent with what's currently in the macro files. 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 |
|
From: Rod J. <rod...@in...> - 2004-07-19 11:39:44
|
I'm not convinced that it's worth changing, especially as the change woul= d obviously have quite an impact in the long term. The present use of "interceptor" in properties--e.g. "interceptorNames", is a bit misleading= , as Interceptors, other Advices or Advisors can be used. However, such methods are *not* parallel to the addInterceptor/addAdvice methods on AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you c= an add ThrowsAdvice as well as interceptors--but it doesn't support adding Advisors. The "interceptorNames" style properties support Advices (includ= ing Interceptors) and Advisors. It's hard to find a convincing name for the latter combination. It's essentially Object-typed. Thus the "interceptor" concept, while an implementation feature rather than AOP essential, seems as good as any. Rgds Rod ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Monday, July 19, 2004 11:36 AM Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1 I forgot: - We need to get "advice" vs "interceptor" naming right, possibly using t= he term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBea= n, TransactionProxyFactoryBean. Juergen ________________________________ Von: spr...@li... im Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Mo 19.07.2004 11:29 An: spr...@li... Betreff: [Springframework-developer] Final preparations for 1.1 RC1 Everybody, Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope: - Mark has provided a refined version of the JMS support - Thomas has already added support for JDBC-generated keys - Darren has committed bind support for Velocity and FreeMarker - Seth has contributed some tag refinements for JSP views. The remaining tasks that I see are: - We need to adapt the source code formatting of the JMS support: I still see nasty empty lines after each code line on Windows: maybe Unix/Windows line feed differences? - I'd like to review the source code of the final version of JMS support. Just about polishing and javadoc, as always before a release :-) - Thomas is already working on using a single API approach for JDBC-generated keys, including moving the classes to a different package. - 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'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. - We need to add Seth's NestedPathTag and include his BindTag refinements. I'll do this myself during the course of the week. All things considered, this means a release by the end of the week: Any earlier date would require dropping one of those tasks, which I don't thi= nk would be worth it. Thoughts? Finally, regarding form simplification macros, i.e. Struts-style HTML inp= ut tag wrappers: Do we already have something here, for either JSP 2.0, Velocity or FreeMarker? Juergen ------------------------------------------------------- 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=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
