Menu
▾
▴
Re: [Springframework-developer] Final preparations for 1.1 RC1
|
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 |
