"Nathan Bubna" <[EMAIL PROTECTED]> writes:
> Daniel Rall said:
> > VelocityServlet doesn't currently support the ability to override the
> > character encoding of its output on a per-request basis. Instead,
> > it's hard-wired to the single value from the configuratin of the
> > RuntimeSingleton. For I18N'd applications, this is painful. The pain
> > can be alleviated by inserting a hook method for determining the
> > output character encoding to use on a per-request basis.
>
> makes sense to me. and, of course, such a change should be mirrored in the
> VelocityViewServlet.
Okay.
...
> > Though this a backwards incompatible change, I estimate that in
> > 85% of use cases this change will be transparent, as a Latin-1
> > encoding (e.g. ISO-8859-1) will generally already be in use.
>
> why not create it with a deprecation/migration path? e.g.
I've always been a fan of getting that as Right as possible. =)
> during init, do:
>
> encoding =
> RuntimeSingleton.getString(RuntimeSingleton.OUTPUT_ENCODING);
>
>
> and in mergeTemplate, get the encoding from this method:
>
> protected String getCharacterEncoding(Context context,
> HttpServletResponse response)
> {
> if (encoding == null)
> {
> String enc = response.getCharacterEncoding();
> if (enc == null)
> {
> enc = DEFAULT_OUTPUT_ENCODING;
> }
> return enc;
> }
> return encoding;
> }
>
> this way, if they are specifying their encoding in the
> velocity.properties, it will still work.
"It" being the old behavior, yeah. However, I contend that the old
behavior is somewhat broken (especially for dynamic I18N'd
applications), and thus think that we should move away from it.
HTTP servlets should not be writing a single response in multiple
encodings unless they're using an encoding like UTF-8 which offers
support for multiple character sets. Specifying one encoding in your
velocity.properties and another for any other output generated by your
servlet will cause exactly this to happen. For instance, if your
servlet is outputing Shift_JIS with a big chunk of ISO-8859-1 in the
middle, the content displayed to the end user is going to be
completely horked.
> also, if we're sure that we want to move away from that method, then
> we can log a deprecation warning during initialization if the
> encoding property is not null.
...
What happens when I want to use my velocity.properties for more than
one VelocityEngine/RuntimeInstance? For servlet output, I may want my
encoding to be determined dynamically (perhaps based on the client's
Accept-Language header), while XML written on the server side using
Velocity I always want to use a specific encoding (e.g. ISO-8859-1).
Most developers will probably avoid the issue entirely by using an
encoding like UTF-8 which supports multiple character sets (and is
used internally by Sun's library implementation). However, I contest
that we shouldn't force this VelocityServlet developers, as
requirements will vary.
What applications are affected?:
Latin-1: Not affected.
Assumption: Both Velocity and their servlet container is using an
ISO-8859-1 encoding.
UTF-8: Not affected.
Assumption: Servlet is already using UTF-8 to handle UTF-8 output from
Velocity, or Velocity was outputting ISO-8859-1 and servlet was using
UTF-8.
Other native encoding: Possibly affected.
Assumption: Developers worked around limitations of current
VelocityServlet implementation in a custom fashion which may or may
not be impacted by this change. Those who simply kept their
velocity.properties and servlet output encoding in sync will not be
affected.
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
