You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2003/10/02 01:33:07 UTC
Re: Velocity[View]Servlet and output encoding
resurrecting an oldish thread...
Daniel, can you enlighten me on why you ended up solving this in the
VelocityServlet the way you did? i want to port this fix over to the
VelocityViewServlet, but i gotta admit your solution looks ugly to me. i'm
assuming there's good reason for it, but i can't quite figure it out. the
solutions we'd discussed earlier in this thread still seem clearer to me.
Nathan Bubna
nathan@esha.com
Daniel Rall said:
> "Nathan Bubna" <na...@esha.com> 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.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Daniel Rall said:
> Nathan Bubna wrote:
> > Geir Magnusson Jr. said:
> >>On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote:
...
> I'm fine with deprecating VS, and am willing to modify Eyebrowse to use VVS.
> Would it be possible (and backwards compatible) for VS to sub-class VVS
> during VS's deprecation period?
hmm. well, VVS doesn't support the old init props key. also, it exposes the
request and response as $request and $response instead of $req and $res.
there have been various other improvements/changes (servlet logger,
WebappLoader, toolbox support, not using getRealPath(), etc.), but i can't
think of anything else that would break b.c..
> Regarding, use of getWriter(), I'm a strong +1. Use of getOutputStream()
only
> makes sense when dealing with binary data, which doesn't seem to fit with
the
> Velocity/Tools use model -- requiring some custom code here strikes me as
just
> fine.
agreed.
> >>>2. drop any explicit dealings with encoding in the VVS. note that we
> >>>can do this only if we do #1. this is because according to
> >>>http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/
> >>>ServletResponse.html#getWriter()
> >>>determination of the PrintWriter's encoding is determined by
> >>>response.setContentType(str) (as long as it's called before
> >>>getWriter(), and
> >>>it is). this should make the VVS's setContentType(req,res)
> >>>sufficient, and we
> >>>won't need to mess with encoding stuff during mergeTemplate() anymore.
> >>>so, for those wanting to set the charset (character encoding)
> >>>per-application,
> >>>they then need only set it as part of their content-type in their
> >>>velocity.properties. (i suppose we could also still accept an encoding
> >>>separately in velocity.props and concat it to the content-type during
> >>>servlet init)
>
> Examation of HTTP shows that the protocol is built to support content
> negotiation. APIs to facilitate content negotiation are extremely important
for
> any I18N'd web application. I've made implementation of dynamic response
> encoding selection trivial, why drop support for it?
>
> >>Won't that be confusing?
> >
> > i don't think so. as it is, they can already specify charset as part of
their
> > default.contentType in their velocity.properties.
>
> Uh oh. The charset portion default.contentType overlaps the output.encoding
> property. That is badness. It must be very clear to the user which
property to
> use, and if they continue to overlap, which takes precedence. Is this
> documented anywhere?
doubt it.
> > after all, it's the way the
> > servlet API is set up; there's no setCharset() method for ServletResponse.
> > also, if we take my parenthesized suggestion, then that should provide
them a
> > way to specify content-type and charset separately. would that be
> > non-confusing enough?
>
> This is what I've done in VS.
yes, but you do it for every request. i would only do it on init.
> >>>for those wanting per-request configuration of the charset, they can
> >>>override
> >>>the VVS's setContentType(req, res) method to implement this as they
> >>>please.
> >>>(though i'm open to suggestions on ways to make this easier for them,
> >>>if you like.)
> >>>
> >>>thoughts?
>
> This I introduced VS's chooseCharacterEncoding() method to provide easier
access
> to the response encoding. What you suggest here is effectively equivalent,
but
> requires more work on the extending developer's part. Why not leave it
easy?
it wouldn't be that much more work. i also just noticed in the servlet docs
that response.setLocale() will set the charset automatically when appropriate.
that's another tool that may make the extending developer's job easier.
that said, i'm not deeply opposed to having a chooseCharacterEncoding()
method, i just think it's unnecessary and could be done more efficiently. if
you're sure you want it, then i'll implement it in VVS, and try to avoid some
of that "ugliness" that bothers me. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 6, 2003, at 04:38 PM, Daniel Rall wrote:
> Daniel Rall wrote:
> ...
>> I'm fine with deprecating VS, and am willing to modify Eyebrowse to
>> use VVS. Would it be possible (and backwards compatible) for VS to
>> sub-class VVS during VS's deprecation period?
>
> Nix that sub-class suggestion; it would create a dependency in the
> wrong direction (Velocity depending upon Velocity Tools).
>
:)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall wrote:
...
> I'm fine with deprecating VS, and am willing to modify Eyebrowse to use
> VVS. Would it be possible (and backwards compatible) for VS to sub-class
> VVS during VS's deprecation period?
Nix that sub-class suggestion; it would create a dependency in the wrong
direction (Velocity depending upon Velocity Tools).
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>
>>On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote:
>
> ...
>
>>>here's what i'm leaning toward for the VVS
>>>(no opinion yet as to whether VelocityServlet should do the same):
>>>
>>>1. take Matthew's suggestion and use response.getWriter() instead of
>>>getOutputStream(). (also use getWriter() in the error() method.)
>>
>>I think we should do this in VelocityServlet for consistency. I'd like
>>to see VS go and point people towards VVS, but for backwards compat, we
>>should keep it around.
>
> ok.
I'm fine with deprecating VS, and am willing to modify Eyebrowse to use VVS.
Would it be possible (and backwards compatible) for VS to sub-class VVS during
VS's deprecation period?
Regarding, use of getWriter(), I'm a strong +1. Use of getOutputStream() only
makes sense when dealing with binary data, which doesn't seem to fit with the
Velocity/Tools use model -- requiring some custom code here strikes me as just fine.
>>>2. drop any explicit dealings with encoding in the VVS. note that we
>>>can do this only if we do #1. this is because according to
>>>http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/
>>>ServletResponse.html#getWriter()
>>>determination of the PrintWriter's encoding is determined by
>>>response.setContentType(str) (as long as it's called before
>>>getWriter(), and
>>>it is). this should make the VVS's setContentType(req,res)
>>>sufficient, and we
>>>won't need to mess with encoding stuff during mergeTemplate() anymore.
>>>so, for those wanting to set the charset (character encoding)
>>>per-application,
>>>they then need only set it as part of their content-type in their
>>>velocity.properties. (i suppose we could also still accept an encoding
>>>separately in velocity.props and concat it to the content-type during
>>>servlet init)
Examation of HTTP shows that the protocol is built to support content
negotiation. APIs to facilitate content negotiation are extremely important for
any I18N'd web application. I've made implementation of dynamic response
encoding selection trivial, why drop support for it?
>>Won't that be confusing?
>
> i don't think so. as it is, they can already specify charset as part of their
> default.contentType in their velocity.properties.
Uh oh. The charset portion default.contentType overlaps the output.encoding
property. That is badness. It must be very clear to the user which property to
use, and if they continue to overlap, which takes precedence. Is this
documented anywhere?
> after all, it's the way the
> servlet API is set up; there's no setCharset() method for ServletResponse.
> also, if we take my parenthesized suggestion, then that should provide them a
> way to specify content-type and charset separately. would that be
> non-confusing enough?
This is what I've done in VS.
>>>for those wanting per-request configuration of the charset, they can
>>>override
>>>the VVS's setContentType(req, res) method to implement this as they
>>>please.
>>>(though i'm open to suggestions on ways to make this easier for them,
>>>if you like.)
>>>
>>>thoughts?
This I introduced VS's chooseCharacterEncoding() method to provide easier access
to the response encoding. What you suggest here is effectively equivalent, but
requires more work on the extending developer's part. Why not leave it easy?
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 6, 2003, at 03:23 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote:
> ...
>>> here's what i'm leaning toward for the VVS
>>> (no opinion yet as to whether VelocityServlet should do the same):
>>>
>>> 1. take Matthew's suggestion and use response.getWriter() instead of
>>> getOutputStream(). (also use getWriter() in the error() method.)
>>
>> I think we should do this in VelocityServlet for consistency. I'd
>> like
>> to see VS go and point people towards VVS, but for backwards compat,
>> we
>> should keep it around.
>
> ok.
Is there a simple, basic example of using VVS?
>>>
>>> so, for those wanting to set the charset (character encoding)
>>> per-application,
>>> they then need only set it as part of their content-type in their
>>> velocity.properties. (i suppose we could also still accept an
>>> encoding
>>> separately in velocity.props and concat it to the content-type during
>>> servlet
>>> init)
>>
>> Won't that be confusing?
>
> i don't think so. as it is, they can already specify charset as part
> of their
> default.contentType in their velocity.properties. after all, it's the
> way the
> servlet API is set up; there's no setCharset() method for
> ServletResponse.
> also, if we take my parenthesized suggestion, then that should provide
> them a
> way to specify content-type and charset separately. would that be
> non-confusing enough?
I think so. I'll have to take a look again at VS. It's been a while,
but I remember it was confusing for some poeple - I'm just thinking
that if you have a better, cleaner way, we should use that.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote:
...
> > here's what i'm leaning toward for the VVS
> > (no opinion yet as to whether VelocityServlet should do the same):
> >
> > 1. take Matthew's suggestion and use response.getWriter() instead of
> > getOutputStream(). (also use getWriter() in the error() method.)
>
> I think we should do this in VelocityServlet for consistency. I'd like
> to see VS go and point people towards VVS, but for backwards compat, we
> should keep it around.
ok.
> > 2. drop any explicit dealings with encoding in the VVS. note that we
> > can do
> > this only if we do #1. this is because according to
> > http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/
> > ServletResponse.html#getWriter()
> > determination of the PrintWriter's encoding is determined by
> > response.setContentType(str) (as long as it's called before
> > getWriter(), and
> > it is). this should make the VVS's setContentType(req,res)
> > sufficient, and we
> > won't need to mess with encoding stuff during mergeTemplate() anymore.
> >
> > so, for those wanting to set the charset (character encoding)
> > per-application,
> > they then need only set it as part of their content-type in their
> > velocity.properties. (i suppose we could also still accept an encoding
> > separately in velocity.props and concat it to the content-type during
> > servlet
> > init)
>
> Won't that be confusing?
i don't think so. as it is, they can already specify charset as part of their
default.contentType in their velocity.properties. after all, it's the way the
servlet API is set up; there's no setCharset() method for ServletResponse.
also, if we take my parenthesized suggestion, then that should provide them a
way to specify content-type and charset separately. would that be
non-confusing enough?
> > for those wanting per-request configuration of the charset, they can
> > override
> > the VVS's setContentType(req, res) method to implement this as they
> > please.
> > (though i'm open to suggestions on ways to make this easier for them,
> > if you
> > like.)
> >
> > thoughts?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote:
> Daniel L. Rall said:
>> Nathan Bubna wrote:
>>> Daniel L. Rall said:
> ...
>>> but what really bugs me is that the string manipulation
>>> apparently will occur for every request, whether dynamic selection of
> output
>>> encoding occurs for that request or not. when i port this to the
>>> VVS, i'd
>>> rather implement it in a way that only does the manipulation when
>>> it's
> needed,
> ...
>> Gotcha. The dynamic selection check always has to occur. Changes to
>> save
> on
>> string manipulation would be preferable, but in the grand scheme of
>> things I
>> didn't see saving on a single StringBuffer worth spending much time
>> on.
> That
>> not withstanding, I'm be happy to discuss any improvement proposal
>> you come
>> up with.
>
> alright. after looking a little more at your content-type code, the
> servlet
> API, and Matthew Payne's proposal, here's what i'm leaning toward for
> the VVS
> (no opinion yet as to whether VelocityServlet should do the same):
>
> 1. take Matthew's suggestion and use response.getWriter() instead of
> getOutputStream(). (also use getWriter() in the error() method.)
I think we should do this in VelocityServlet for consistency. I'd like
to see VS go and point people towards VVS, but for backwards compat, we
should keep it around.
>
> 2. drop any explicit dealings with encoding in the VVS. note that we
> can do
> this only if we do #1. this is because according to
> http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/
> ServletResponse.html#getWriter()
> determination of the PrintWriter's encoding is determined by
> response.setContentType(str) (as long as it's called before
> getWriter(), and
> it is). this should make the VVS's setContentType(req,res)
> sufficient, and we
> won't need to mess with encoding stuff during mergeTemplate() anymore.
>
> so, for those wanting to set the charset (character encoding)
> per-application,
> they then need only set it as part of their content-type in their
> velocity.properties. (i suppose we could also still accept an encoding
> separately in velocity.props and concat it to the content-type during
> servlet
> init)
Won't that be confusing?
>
> for those wanting per-request configuration of the charset, they can
> override
> the VVS's setContentType(req, res) method to implement this as they
> please.
> (though i'm open to suggestions on ways to make this easier for them,
> if you
> like.)
>
> thoughts?
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Daniel L. Rall said:
> Nathan Bubna wrote:
> > Daniel L. Rall said:
...
> > but what really bugs me is that the string manipulation
> > apparently will occur for every request, whether dynamic selection of
output
> > encoding occurs for that request or not. when i port this to the VVS, i'd
> > rather implement it in a way that only does the manipulation when it's
needed,
...
> Gotcha. The dynamic selection check always has to occur. Changes to save
on
> string manipulation would be preferable, but in the grand scheme of things I
> didn't see saving on a single StringBuffer worth spending much time on.
That
> not withstanding, I'm be happy to discuss any improvement proposal you come
> up with.
alright. after looking a little more at your content-type code, the servlet
API, and Matthew Payne's proposal, here's what i'm leaning toward for the VVS
(no opinion yet as to whether VelocityServlet should do the same):
1. take Matthew's suggestion and use response.getWriter() instead of
getOutputStream(). (also use getWriter() in the error() method.)
2. drop any explicit dealings with encoding in the VVS. note that we can do
this only if we do #1. this is because according to
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletResponse.html#getWriter()
determination of the PrintWriter's encoding is determined by
response.setContentType(str) (as long as it's called before getWriter(), and
it is). this should make the VVS's setContentType(req,res) sufficient, and we
won't need to mess with encoding stuff during mergeTemplate() anymore.
so, for those wanting to set the charset (character encoding) per-application,
they then need only set it as part of their content-type in their
velocity.properties. (i suppose we could also still accept an encoding
separately in velocity.props and concat it to the content-type during servlet
init)
for those wanting per-request configuration of the charset, they can override
the VVS's setContentType(req, res) method to implement this as they please.
(though i'm open to suggestions on ways to make this easier for them, if you
like.)
thoughts?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Daniel Rall said:
> Nathan Bubna wrote:
> > Geir Magnusson Jr. said:
> >>On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
> >>>me too. maybe it's time for another round of the "switch to
> >>>commons-logging"
> >>>debate. :)
>
> I'm game. ;)
>
> ...
> >>>ah, but even i don't have time to open any such big cans of worms
> >>>right now.
>
> Yes, that is the heart of the matter, isn't it.
...
> >> I still detest the commons-logging idea though.
> >
> > heh. though i haven't the time ATM, i'll be happy to take another shot at
> > convincing you later. :) in fact, you can probably count on it coming up
> > again. ;)
>
> I'd appreciate it if someone would post a link to previous discussion before
we
> start re-hashing things.
before i start any re-hashing of this, i will. but like i said, i don't have
the time to start that now. if you want the links, go find 'em yourself. :)
> > ...
> >>>there was talk of taking servlet-related stuff out of
> >>>velocity's core altogether, and i think i'd be likely to support that.
> >>
> >>I think that it would be good for Velocity, and good for vel tools. I
> >>am going to punch together a 1.4 rel this week, and maybe we should
> >>deprecate VS right now.
> >
> > i'm ok with that.
>
> In light of Nathan's explaination and proposal, +1.
>
> Looking forward to the 1.4 release! Speaking of which, should I just pull a
> 1.3.1 tree and to put up on the mirrorable download site? Should I remove
its
> CVS meta data dirs or leave them?
>
> >>We'll need a simple-stupid example, though in
> >>v-t to replace it. I think it's key that there is a trivial example of
> >>how to use it.
> >>
> >>Thoughts?
> >
> > we do have a 'simple' example in veltools. if it needs to be simpler,
then
> > that should be easy enough.
>
> Mind posting the URL to the example/documentation? We should link to it
from
> any references to the old VelocityServlet.
the 'simple' example code is here:
http://cvs.apache.org/viewcvs/jakarta-velocity-tools/examples/simple/
the example webapps come ready-to-go as WARs packaged in the velocity-tools
binary distribution. brief instructions for them are also here:
http://jakarta.apache.org/velocity/tools/view/index.html#Examples
VVS documentation is largely here:
http://jakarta.apache.org/velocity/tools/view/
VVS javadoc is here:
http://nagoya.apache.org/gump/javadoc/jakarta-velocity-tools/docs/javadoc/org/apache/velocity/tools/view/servlet/VelocityViewServlet.html
also, if we are going to move VelocityServlet out of Velocity, we should
probably copy over & adapt the developer's guide section on "Using Velocity in
Servlets" to be part of the veltools docs and then just have the core's dev
guide link to that.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>
>>On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
>>
>>>>I wish I had a way to check the log level to avoid unnecessary string
>>>>manipulation when logging.
>>>
>>>me too. maybe it's time for another round of the "switch to
>>>commons-logging"
>>>debate. :)
I'm game. ;)
...
>>>ah, but even i don't have time to open any such big cans of worms
>>>right now.
Yes, that is the heart of the matter, isn't it.
...
>>I concluded my employment last tuesday!
>
> oh. so... are congratulations or condolences in order here?
Congratulations!
>> I still detest the commons-logging idea though.
>
> heh. though i haven't the time ATM, i'll be happy to take another shot at
> convincing you later. :) in fact, you can probably count on it coming up
> again. ;)
I'd appreciate it if someone would post a link to previous discussion before we
start re-hashing things.
> ...
>>>there was talk of taking servlet-related stuff out of
>>>velocity's core altogether, and i think i'd be likely to support that.
>>
>>I think that it would be good for Velocity, and good for vel tools. I
>>am going to punch together a 1.4 rel this week, and maybe we should
>>deprecate VS right now.
>
> i'm ok with that.
In light of Nathan's explaination and proposal, +1.
Looking forward to the 1.4 release! Speaking of which, should I just pull a
1.3.1 tree and to put up on the mirrorable download site? Should I remove its
CVS meta data dirs or leave them?
>>We'll need a simple-stupid example, though in
>>v-t to replace it. I think it's key that there is a trivial example of
>>how to use it.
>>
>>Thoughts?
>
> we do have a 'simple' example in veltools. if it needs to be simpler, then
> that should be easy enough.
Mind posting the URL to the example/documentation? We should link to it from
any references to the old VelocityServlet.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Monday, October 6, 2003, at 03:31 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr. said:
> >> On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
> >>>Daniel Rall said:
> >>>> I wish I had a way to check the log level to avoid unnecessary
> >>>> string
> >>>> manipulation when logging.
> >>>
> >>> me too. maybe it's time for another round of the "switch to
> >>> commons-logging"
> >>> debate. :)
> >>>
> >>> <sidenote type="volatile">
> >>> actually, in all seriousness, how many major development threads in
> >>> the last
> >>> year have died without resolution or had resolution but never been
> >>> acted on?
> >>> commons-logging, map syntax, float support, whitespace... the list
> >>> goes on.
> >>> ah, but even i don't have time to open any such big cans of worms
> >>> right now.
> >>> :( <sigh /> surely somewhere out there there is a developer willing
> >>> and able
> >>> to slave away on these things?
> >>> </sidenote>
> >>>
> >>
> >> I'm actually willing and able. I concluded my employment last
> >> tuesday!
> >
> > oh. so... are congratulations or condolences in order here?
>
> Congratulations and joy! I resigned 3 months ago - there was a 3 mo
> notice into my contract to ensure that my position could be filled,
> transfer of responsibilities, etc. But it's really hard to work
> someplace that you quit for 3 months. It takes quite a bit of drive
> and focus to want to get up in the morning and do it, because you know
> that it's ending. However, I did it, and I think I did a good and
> responsible job. I'm glad its done - time to move on to bigger and
> better things. (And I don't sleep with a cellphone anymore).
>
> Now that it's over, I'm able to now to do all the things I want to do,
> as I have the time. There are a few other irons in the fire, and I'm
> always looking for cool design or development projects, but right now
> I'll enjoy the free time and try to catch up in several places that
> I've been meaning to. (hint hint)
my sincere congratulations! :)
> >
> >> I still detest the commons-logging idea though.
> >
> > heh. though i haven't the time ATM, i'll be happy to take another
> > shot at
> > convincing you later. :) in fact, you can probably count on it
> > coming up
> > again. ;)
>
> I'm sure it will. Given the virulent nature of this pestilence....
>
> In all seriousness, I think that we should support those who need to
> use c-l in some way, but not convinced that that we should rip up the
> core and force people to use it.
<large-worm-can action="barely crack open">
if you'll note Daniel's original comment (way up at the top), it's not really
that we need c-l, it's that we need and/or greatly desire it's features. why
maintain our own "mini-commons-logging" in Velocity when there's a better one
ready to go?
</large-worm-can>
<large-worm-can action="slam shut">
but seriously, i really think this is *NOT* the time for this discussion.
i've personally got higher priorities right now, and i think Velocity as a
project presently has more pressing concerns as well.
</large-worm-can>
> > ...
> >>> there was talk of taking servlet-related stuff out of
> >>> velocity's core altogether, and i think i'd be likely to support
> >>> that.
> >>
> >> I think that it would be good for Velocity, and good for vel tools. I
> >> am going to punch together a 1.4 rel this week, and maybe we should
> >> deprecate VS right now.
> >
> > i'm ok with that.
> >
> >> We'll need a simple-stupid example, though in
> >> v-t to replace it. I think it's key that there is a trivial example
> >> of
> >> how to use it.
> >>
> >> Thoughts?
> >
> > we do have a 'simple' example in veltools. if it needs to be simpler,
> > then
> > that should be easy enough.
>
> If it's of the order of
>
> 1) install tomcat or jetty (I adore jetty, btw)
>
> 2) drop the .war in the <foo> directory
>
> 3) light and get away
>
> that should be plenty - it's what we try to have in the vel exmaples,
> and we could just point people at that.
that's precisely what we've got. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 6, 2003, at 03:31 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
>>>> I wish I had a way to check the log level to avoid unnecessary
>>>> string
>>>> manipulation when logging.
>>>
>>> me too. maybe it's time for another round of the "switch to
>>> commons-logging"
>>> debate. :)
>>>
>>> <sidenote type="volatile">
>>> actually, in all seriousness, how many major development threads in
>>> the last
>>> year have died without resolution or had resolution but never been
>>> acted on?
>>> commons-logging, map syntax, float support, whitespace... the list
>>> goes on.
>>> ah, but even i don't have time to open any such big cans of worms
>>> right now.
>>> :( <sigh /> surely somewhere out there there is a developer willing
>>> and able
>>> to slave away on these things?
>>> </sidenote>
>>>
>>
>> I'm actually willing and able. I concluded my employment last
>> tuesday!
>
> oh. so... are congratulations or condolences in order here?
Congratulations and joy! I resigned 3 months ago - there was a 3 mo
notice into my contract to ensure that my position could be filled,
transfer of responsibilities, etc. But it's really hard to work
someplace that you quit for 3 months. It takes quite a bit of drive
and focus to want to get up in the morning and do it, because you know
that it's ending. However, I did it, and I think I did a good and
responsible job. I'm glad its done - time to move on to bigger and
better things. (And I don't sleep with a cellphone anymore).
Now that it's over, I'm able to now to do all the things I want to do,
as I have the time. There are a few other irons in the fire, and I'm
always looking for cool design or development projects, but right now
I'll enjoy the free time and try to catch up in several places that
I've been meaning to. (hint hint)
>
>> I still detest the commons-logging idea though.
>
> heh. though i haven't the time ATM, i'll be happy to take another
> shot at
> convincing you later. :) in fact, you can probably count on it
> coming up
> again. ;)
I'm sure it will. Given the virulent nature of this pestilence....
In all seriousness, I think that we should support those who need to
use c-l in some way, but not convinced that that we should rip up the
core and force people to use it.
>
> ...
>>> there was talk of taking servlet-related stuff out of
>>> velocity's core altogether, and i think i'd be likely to support
>>> that.
>>
>> I think that it would be good for Velocity, and good for vel tools. I
>> am going to punch together a 1.4 rel this week, and maybe we should
>> deprecate VS right now.
>
> i'm ok with that.
>
>> We'll need a simple-stupid example, though in
>> v-t to replace it. I think it's key that there is a trivial example
>> of
>> how to use it.
>>
>> Thoughts?
>
> we do have a 'simple' example in veltools. if it needs to be simpler,
> then
> that should be easy enough.
If it's of the order of
1) install tomcat or jetty (I adore jetty, btw)
2) drop the .war in the <foo> directory
3) light and get away
that should be plenty - it's what we try to have in the vel exmaples,
and we could just point people at that.
geir
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
> >> I wish I had a way to check the log level to avoid unnecessary string
> >> manipulation when logging.
> >
> > me too. maybe it's time for another round of the "switch to
> > commons-logging"
> > debate. :)
> >
> > <sidenote type="volatile">
> > actually, in all seriousness, how many major development threads in
> > the last
> > year have died without resolution or had resolution but never been
> > acted on?
> > commons-logging, map syntax, float support, whitespace... the list
> > goes on.
> > ah, but even i don't have time to open any such big cans of worms
> > right now.
> > :( <sigh /> surely somewhere out there there is a developer willing
> > and able
> > to slave away on these things?
> > </sidenote>
> >
>
> I'm actually willing and able. I concluded my employment last tuesday!
oh. so... are congratulations or condolences in order here?
> I still detest the commons-logging idea though.
heh. though i haven't the time ATM, i'll be happy to take another shot at
convincing you later. :) in fact, you can probably count on it coming up
again. ;)
...
> > there was talk of taking servlet-related stuff out of
> > velocity's core altogether, and i think i'd be likely to support that.
>
> I think that it would be good for Velocity, and good for vel tools. I
> am going to punch together a 1.4 rel this week, and maybe we should
> deprecate VS right now.
i'm ok with that.
> We'll need a simple-stupid example, though in
> v-t to replace it. I think it's key that there is a trivial example of
> how to use it.
>
> Thoughts?
we do have a 'simple' example in veltools. if it needs to be simpler, then
that should be easy enough.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Sunday, October 5, 2003, at 07:55 PM, Nathan Bubna wrote:
>> I wish I had a way to check the log level to avoid unnecessary string
>> manipulation when logging.
>
> me too. maybe it's time for another round of the "switch to
> commons-logging"
> debate. :)
>
> <sidenote type="volatile">
> actually, in all seriousness, how many major development threads in
> the last
> year have died without resolution or had resolution but never been
> acted on?
> commons-logging, map syntax, float support, whitespace... the list
> goes on.
> ah, but even i don't have time to open any such big cans of worms
> right now.
> :( <sigh /> surely somewhere out there there is a developer willing
> and able
> to slave away on these things?
> </sidenote>
>
I'm actually willing and able. I concluded my employment last tuesday!
I still detest the commons-logging idea though.
>
> ...
>>> VelocityViewServlet does not extend the VelocityServlet, nor has it
>>> for
> quite
>>> some time. it was decide long ago that VelocityTools development
>>> was and
>>> would be significantly impeded by such dependence on Velocity's
>>> present
>>> development rate and release cycle. the superclass of
>>> VelocityViewServlet
> is
>>> HttpServlet.
>>
>> Ah, I wasn't aware of that. It would reduce code duplication to use
>> a VS or
>> utility instance as a helper variable in VVS's implementation. Is a
>> helper
>> object something wich you would find useful? It would certainly
>> reduce
>> porting overhead.
>
> hmm. i gotta admit i'm not very keen on this right now. first off,
> VelocityServlet just isn't up to speed. VVS has a number of
> improvements.
> even when/if VS gets to that point, older versions still wouldn't be,
> so that
> would cost version flexibility. last, during the aforementioned
> discussion/decision, there was talk of taking servlet-related stuff
> out of
> velocity's core altogether, and i think i'd be likely to support that.
I think that it would be good for Velocity, and good for vel tools. I
am going to punch together a 1.4 rel this week, and maybe we should
deprecate VS right now. We'll need a simple-stupid example, though in
v-t to replace it. I think it's key that there is a trivial example of
how to use it.
Thoughts?
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Nathan Bubna <na...@esha.com>.
Daniel L. Rall said:
> Nathan Bubna wrote:
...
> > as for the "ugliness," the commented-out Sys.out.print()s immediately
drive me
> > to suspicion ;)
>
> Hehe, how's this:
...
> - //System.out.println("Chose output encoding of '" +
> - // encoding + '\'');
> + RuntimeSingleton.debug("Chose output encoding of '" +
> + encoding + '\'');
...
:)
> I wish I had a way to check the log level to avoid unnecessary string
> manipulation when logging.
me too. maybe it's time for another round of the "switch to commons-logging"
debate. :)
<sidenote type="volatile">
actually, in all seriousness, how many major development threads in the last
year have died without resolution or had resolution but never been acted on?
commons-logging, map syntax, float support, whitespace... the list goes on.
ah, but even i don't have time to open any such big cans of worms right now.
:( <sigh /> surely somewhere out there there is a developer willing and able
to slave away on these things?
</sidenote>
> > but what really bugs me is that the string manipulation
> > apparently will occur for every request, whether dynamic selection of
output
> > encoding occurs for that request or not. when i port this to the VVS, i'd
> > rather implement it in a way that only does the manipulation when it's
needed,
> > but i didn't want to miss any important/necessary subtlety included in
your
> > implementation. thus... i was largely requesting *clarification* of the
> > reasoning behind implementation, not justification of it.
>
> Gotcha. The dynamic selection check always has to occur. Changes to save
on
> string manipulation would be preferable, but in the grand scheme of things I
> didn't see saving on a single StringBuffer worth spending much time on.
That
> not withstanding, I'm be happy to discuss any improvement proposal you come
up
> with.
ok, i'll try to stash a little time this week to look at this again. i also
need to look a little more into the "switch to response.getWriter() proposal"
by Matthew Payne. it sounds like a good idea, but i'm a little wary of how it
will affect these encoding issues. i'm beginning to suspect it may actually
simplify them and be a key to finding a more elegant solution. also, i need
to keep in mind the VelocityLayoutServlet and make sure it's two-step
processing keeps in step with these things.
...
> > VelocityViewServlet does not extend the VelocityServlet, nor has it for
quite
> > some time. it was decide long ago that VelocityTools development was and
> > would be significantly impeded by such dependence on Velocity's present
> > development rate and release cycle. the superclass of VelocityViewServlet
is
> > HttpServlet.
>
> Ah, I wasn't aware of that. It would reduce code duplication to use a VS or
> utility instance as a helper variable in VVS's implementation. Is a helper
> object something wich you would find useful? It would certainly reduce
> porting overhead.
hmm. i gotta admit i'm not very keen on this right now. first off,
VelocityServlet just isn't up to speed. VVS has a number of improvements.
even when/if VS gets to that point, older versions still wouldn't be, so that
would cost version flexibility. last, during the aforementioned
discussion/decision, there was talk of taking servlet-related stuff out of
velocity's core altogether, and i think i'd be likely to support that.
so basically, at least at this time, i'm thinking this wouldn't be worth the
cost/effort. but depending on what direction the core takes, i suppose it
might be worthwhile in the future.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> Daniel L. Rall said:
>
>>Nathan Bubna wrote:
>>
>>>resurrecting an oldish thread...
>>>
>>>Daniel, can you enlighten me on why you ended up solving this in the
>>>VelocityServlet the way you did? i want to port this fix over to the
>>>VelocityViewServlet, but i gotta admit your solution looks ugly to me.
>>
>>Sure! Would you be more specific about what "looks ugly"? If you're
>>referring to the string manipulation, well, that's just how this sort of
>>thing is done in servlet land:
>
> "that's how everyone's doing it" or "that's how so-and-so does it" rarely
> satiates me. i'm generally one of those hopeless, foolish, "there must be a
> more elegant way" idealists. :)
>
> as for the "ugliness," the commented-out Sys.out.print()s immediately drive me
> to suspicion ;)
Hehe, how's this:
--- VelocityServlet.java 31 Aug 2003 21:26:52 -0000 1.52
+++ VelocityServlet.java 5 Oct 2003 22:24:36 -0000
@@ -526,16 +526,16 @@
{
// Append the character encoding which we'd like to use.
String encoding = chooseCharacterEncoding(request);
- //System.out.println("Chose output encoding of '" +
- // encoding + '\'');
+ RuntimeSingleton.debug("Chose output encoding of '" +
+ encoding + '\'');
if (!DEFAULT_OUTPUT_ENCODING.equalsIgnoreCase(encoding))
{
contentType += "; charset=" + encoding;
}
}
response.setContentType(contentType);
- //System.out.println("Response Content-Type set to '" +
- // contentType + '\'');
+ RuntimeSingleton.debug("Response Content-Type set to '" +
+ contentType + '\'');
}
/**
I wish I had a way to check the log level to avoid unnecessary string
manipulation when logging.
> but what really bugs me is that the string manipulation
> apparently will occur for every request, whether dynamic selection of output
> encoding occurs for that request or not. when i port this to the VVS, i'd
> rather implement it in a way that only does the manipulation when it's needed,
> but i didn't want to miss any important/necessary subtlety included in your
> implementation. thus... i was largely requesting *clarification* of the
> reasoning behind implementation, not justification of it.
Gotcha. The dynamic selection check always has to occur. Changes to save on
string manipulation would be preferable, but in the grand scheme of things I
didn't see saving on a single StringBuffer worth spending much time on. That
not withstanding, I'm be happy to discuss any improvement proposal you come up
with.
...
>>When porting, please also note that rev 1.50 of VS included a forward-port
>>of Bill Boland's fix for
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18951,
>>so the corresponding code in VelocityViewServlet could possibly be dropped
>>as it is now present in its super class.
> ...
>
> VelocityViewServlet does not extend the VelocityServlet, nor has it for quite
> some time. it was decide long ago that VelocityTools development was and
> would be significantly impeded by such dependence on Velocity's present
> development rate and release cycle. the superclass of VelocityViewServlet is
> HttpServlet.
Ah, I wasn't aware of that. It would reduce code duplication to use a VS or
utility instance as a helper variable in VVS's implementation. Is a helper
object something wich you would find useful? It would certainly reduce
porting overhead.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> resurrecting an oldish thread...
>
> Daniel, can you enlighten me on why you ended up solving this in the
> VelocityServlet the way you did? i want to port this fix over to the
> VelocityViewServlet, but i gotta admit your solution looks ugly to me.
Sure! Would you be more specific about what "looks ugly"? If you're
referring to the string manipulation, well, that's just how this sort of thing
is done in servlet land:
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html#setContentType(java.lang.String)
You'll note that ServletResponse has no setCharacterEncoding() method, and its
header JavaDoc actually incidates that setContentType() should be used to do
just that:
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html
ServletResponse does (un-orthogonally) supply a getCharacterEncoding() method,
which I do use.
When porting, please also note that rev 1.50 of VS included a forward-port of
Bill Boland's fix for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18951,
so the corresponding code in VelocityViewServlet could possibly be dropped as
it is now present in its super class.
> i'm assuming there's good reason for it, but i can't quite figure it out. the
> solutions we'd discussed earlier in this thread still seem clearer to me.
Yeah, seemed like the best way to meet the goals and play nicely with the
implementation/integration technologies. Here's a link to the change:
http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/org/apache/velocity/servlet/VelocityServlet.java.diff?r1=text&tr1=1.50&r2=text&tr2=1.52&diff_format=u
Output encoding is now determined on a per-request basis. This is essential
for allowing dynamic selection of output encoding (e.g. Shift_JIS responses
for "Accept-Language: ja" requests from Tetsuya, ISO-8859-1 responses for
"Accept-Language: en-US" requests from Dan, etc.).
The API for setting the response encoding mirrors what is done by the Servlet
API, which is the most appropriate interface for VelocityServlet. I've had
the questionable honor of reviewing the related portion of Catalina's code
quite a few times.
Here's relevant portions of the CVS change log from rev 1.51:
* src/java/org/apache/velocity/servlet/VelocityServlet.java
encoding: Removed unnecessary class field.
init(): No longer set encoding field.
doRequest(): Moved call to requestCleanup() down into a finally
block. This is a minor change in behavior to supply a much more
useful cleanup hook for cases where unexpected exceptions are
thrown.
mergeTemplate(): Get the character encoding from the
HttpServletResponse object. The assumption is that it has already
been set via a charset= parameter on the Content-Type header.
setContentType(), chooseCharacterEncoding(): Added support for
dynamic selection of response character encoding.
> Daniel Rall said:
>
>>"Nathan Bubna" <na...@esha.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Daniel Dekany wrote:
> Thursday, October 2, 2003, 7:47:12 AM, mailmur wrote:
>
>>Would it be possible to specify an outputencoding
>>directive at the start of velocity template? I believe
>>FreeMarker can do it, but not sure about it.
>
> It can't (out-of-the-box), since it uses a Writer to write the output,
> so it does not deal with output encoding.
Actually, this might be possible since the reading of a template is separate
from the merging of it with a context, but I'd rather not include this sort of
logic in the template -- it's meta data which I feel squeemish about putting
there.
>>I can see it's a bit problem to control outputstream
>>within the template as its too late for such
>>properties.
>
> If the Writer buffers the characters, it is possible to change the
> encoding until the Writer is not flushed, since the encoding will be
> needed only when the Writer flushes its buffer into the underlaying
> OutputStreamWriter. However, in the case of servlers, it has the problem
> that you get a readily made Writer with resp.getWriter, so you can't
> control there things, and using new MyCustomWriter(res.getOutputStream)
> has catches...
When working with Tomcat 4.x's stock HttpServletResponse (specifically, its
setContentType() method), it's not possible to change the output encoding
mid-write (buffered or otherwise).
> But anyway, I think that controlling output encoding in template is
> usually not a good practice. And, I tend to think that the safest is if
> you just use UTF-8 as output encoding everywhere... no "?"-s.
I agree. An uber-encoding like UTF-8 is really the only way to mix character
sets, anyhow.
>>Resourceloader maybe should check it in
>>advance and store template's directives for later use.
>
>
> Maybe introducing general purpose template attributes that can be
> queried before actually executing (merge) the template...
>
> #attribute("outputEncoding", "ISO-8859-5")
> #attribute("cache", "30m")
> ...
>
> So you can assign *any* name-value pairs to templates.
I'd rather see control of meta data happen outside of the body of the template.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by mailmur <ma...@yahoo.com>.
Ok, Ive reverified my original problem what made me to
create a UnicodeFileLoader for velocity.
* Velocitytemplate saved as UTF-8 with BOM
* Use Velocity original FileResourceLoader
* Use input.encoding = UTF-8
* Use outputencoding = ISO-8859-1 (or another legacy
charset)
* Generate as "text/plain" contenttype (or directly to
filestream)
-> Result: Will have ? character at the start. Reason
is Java bug for not recognising UTF8 bom and skip it
for nonunicode charset.
All this work if input.encoding is UTF-16 as Java will
recognize UTF16BE and UTF16LE boms.
Velocityloader with support to recognise BOMs from
templatefile, and skip UTF8 bom marker as well.
http://koti.mbnet.fi/akini/java/unicodereader/
Bug: 4508058
"UTF-8 encoding does not recognize initial BOM"
http://developer.java.sun.com/developer/bugParade/bugs/4508058.html
> > Java does not support UTF8 bom marker and it is a
> bug in current state of unicode standard.
>
> I don't believe that there is such thing that Java
> does not support BOM.
> If the UTF-8 encoder/decoder works for other
> characters, then it should
> work for BOM too. Because, UTF-8 is just a "stupid"
> code-point-array
> <--> byte-array conversion algorithm, and it does
> not deal with the
> meaning of the characters. It only sees their
> code-point (the UCS code).
> I have tried it now. If I create a test_in.txt with
> Notepade+Save-as-UTF-8, then test_in.txt will be
> exactly the same as
> test_out.txt (it will contain the BOM too). At least
> with Win2K + Sun
> J2SE 1.4.2.
>
> Reader r = new InputStreamReader(new
> FileInputStream("somewhere/test_in.txt"), "UTF-8");
> Writer w = new OutputStreamWriter(new
> FileOutputStream("somewhere/test_out.txt"),
> "UTF-8");
> int c;
> while ((c = r.read()) != -1) {
> w.write(c);
> }
> w.close();
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 3, 2003, 7:40:12 AM, mailmur wrote:
>> I feel some confusion here. The thing is that Win2K/XP Notepad adds a
>> BOM character (UCS code FEFF) at the beginning of the file (with
>> UTF-8 encoding, if save with that). That character can be superfluous
>> here (as HTTP has charset given in the content-type header, it
>> doesn't need auto-detection), also some UNICODE aware software
>> doesn't understand what's that BOM there (as Opera Web browser, and
>> it seems, Sun Java platform impl.), but it is still a plain simple
>> character there. So if your *output* encoding is UTF-8, and also
>> Velocity uses UTF-8 *input* (template) encoding, then that must not
>> become to '?'. You see, that's a legal UTF-8 encoded character, so it
>> must remain what it was originally, if the output and input encoding
>> is the same...
>>
>> > But generating "text/plain" from Notepad-UTF8
>> saved
>> > velocity template will output ? character as first
>> > character.
>> I suspect either your input or output encoding is
>> not UTF-8.
>
> But thats how it works with the original
> FileResourceLoader, my testprogram will show it all.
>
> Java does not support UTF8 bom marker and it is a bug
> in current state of unicode standard.
I don't believe that there is such thing that Java does not support BOM.
If the UTF-8 encoder/decoder works for other characters, then it should
work for BOM too. Because, UTF-8 is just a "stupid" code-point-array
<--> byte-array conversion algorithm, and it does not deal with the
meaning of the characters. It only sees their code-point (the UCS code).
I have tried it now. If I create a test_in.txt with
Notepade+Save-as-UTF-8, then test_in.txt will be exactly the same as
test_out.txt (it will contain the BOM too). At least with Win2K + Sun
J2SE 1.4.2.
Reader r = new InputStreamReader(
new FileInputStream("somewhere/test_in.txt"), "UTF-8");
Writer w = new OutputStreamWriter(
new FileOutputStream("somewhere/test_out.txt"), "UTF-8");
int c;
while ((c = r.read()) != -1) {
w.write(c);
}
w.close();
> I save myTemplate.vm as Win2k notepad-UTF8, use
> Velocity inputencoding UTF8, use outputencoding UTF8,
> generate plain text output and will have ? character.
> If I use UTF16 format then all works fine.
>
> My testprogram has a standalone commandline example to
> show it.
I don't know why... Try the above trivial example, and if it works, then
the Velocity stuff does something bad.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by mailmur <ma...@yahoo.com>.
> I feel some confusion here. The thing is that
> Win2K/XP Notepad adds a
> BOM character (UCS code FEFF) at the beginning of
> the file (with UTF-8
> encoding, if save with that). That character can be
> superfluous here (as
> HTTP has charset given in the content-type header,
> it doesn't need
> auto-detection), also some UNICODE aware software
> doesn't understand
> what's that BOM there (as Opera Web browser, and it
> seems, Sun Java
> platform impl.), but it is still a plain simple
> character there. So if
> your *output* encoding is UTF-8, and also Velocity
> uses UTF-8 *input*
> (template) encoding, then that must not become to
> '?'. You see, that's a
> legal UTF-8 encoded character, so it must remain
> what it was originally,
> if the output and input encoding is the same...
>
> > But generating "text/plain" from Notepad-UTF8
> saved
> > velocity template will output ? character as first
> > character.
> I suspect either your input or output encoding is
> not UTF-8.
But thats how it works with the original
FileResourceLoader, my testprogram will show it all.
Java does not support UTF8 bom marker and it is a bug
in current state of unicode standard.
I save myTemplate.vm as Win2k notepad-UTF8, use
Velocity inputencoding UTF8, use outputencoding UTF8,
generate plain text output and will have ? character.
If I use UTF16 format then all works fine.
My testprogram has a standalone commandline example to
show it.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 2, 2003, 12:49:04 PM, mailmur wrote:
>> Daniel Dekany
>> But anyway, I think that controlling output encoding
>> in template is
>> usually not a good practice. And, I tend to think
>> that the safest is if
>> you just use UTF-8 as output encoding everywhere...
>> no "?"-s.
>
> This is what I encountered and had a minor problem in
> Win2k environment (if template is ever saved with
> Notepad UTF8 format). Win-notepad will add UTF8 bom
> marker (3 bytes) at the start...which is a very good
> as programs can transparently handle several encodings
> without an user interaction.
> If velocity is used to generate html files
> (text/html), then extra ? character is not displayed
> at the webbrowser. Maybe browsers recognise the bom
> and will skip it.
I feel some confusion here. The thing is that Win2K/XP Notepad adds a
BOM character (UCS code FEFF) at the beginning of the file (with UTF-8
encoding, if save with that). That character can be superfluous here (as
HTTP has charset given in the content-type header, it doesn't need
auto-detection), also some UNICODE aware software doesn't understand
what's that BOM there (as Opera Web browser, and it seems, Sun Java
platform impl.), but it is still a plain simple character there. So if
your *output* encoding is UTF-8, and also Velocity uses UTF-8 *input*
(template) encoding, then that must not become to '?'. You see, that's a
legal UTF-8 encoded character, so it must remain what it was originally,
if the output and input encoding is the same...
> But generating "text/plain" from Notepad-UTF8 saved
> velocity template will output ? character as first
> character.
I suspect either your input or output encoding is not UTF-8.
> My unicoderesourceloader has a standalone testprogram to see it
> happen.
The resource loader should automatically interpret and remove leading
BOM, as some software is confused on the leading BOM...
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by mailmur <ma...@yahoo.com>.
> Daniel Dekany
> But anyway, I think that controlling output encoding
> in template is
> usually not a good practice. And, I tend to think
> that the safest is if
> you just use UTF-8 as output encoding everywhere...
> no "?"-s.
This is what I encountered and had a minor problem in
Win2k environment (if template is ever saved with
Notepad UTF8 format). Win-notepad will add UTF8 bom
marker (3 bytes) at the start...which is a very good
as programs can transparently handle several encodings
without an user interaction.
If velocity is used to generate html files
(text/html), then extra ? character is not displayed
at the webbrowser. Maybe browsers recognise the bom
and will skip it.
But generating "text/plain" from Notepad-UTF8 saved
velocity template will output ? character as first
character. My unicoderesourceloader has a standalone
testprogram to see it happen.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 2, 2003, 7:47:12 AM, mailmur wrote:
> Would it be possible to specify an outputencoding
> directive at the start of velocity template? I believe
> FreeMarker can do it, but not sure about it.
It can't (out-of-the-box), since it uses a Writer to write the output,
so it does not deal with output encoding.
> I can see it's a bit problem to control outputstream
> within the template as its too late for such
> properties.
If the Writer buffers the characters, it is possible to change the
encoding until the Writer is not flushed, since the encoding will be
needed only when the Writer flushes its buffer into the underlaying
OutputStreamWriter. However, in the case of servlers, it has the problem
that you get a readily made Writer with resp.getWriter, so you can't
control there things, and using new MyCustomWriter(res.getOutputStream)
has catches...
But anyway, I think that controlling output encoding in template is
usually not a good practice. And, I tend to think that the safest is if
you just use UTF-8 as output encoding everywhere... no "?"-s.
> Resourceloader maybe should check it in
> advance and store template's directives for later use.
Maybe introducing general purpose template attributes that can be
queried before actually executing (merge) the template...
#attribute("outputEncoding", "ISO-8859-5")
#attribute("cache", "30m")
...
So you can assign *any* name-value pairs to templates.
[snip]
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity[View]Servlet and output encoding
Posted by mailmur <ma...@yahoo.com>.
Would it be possible to specify an outputencoding
directive at the start of velocity template? I believe
FreeMarker can do it, but not sure about it.
I can see it's a bit problem to control outputstream
within the template as its too late for such
properties. Resourceloader maybe should check it in
advance and store template's directives for later use.
Another issue is inputencoding of template files. Ive
created UnicodeResourceLoader (posted on velocity
bugzilla as enhancement) to give transparent
introspection for unicode files with BOM marker.
http://koti.mbnet.fi/akini/java/unicodereader/
It can transparently read unicode files with the
proper charset if BOM marker is available. Java
currently does not support UTF8 BOM marker, but even
Win2K Notepad can save UTF8withbom. This is where
unicodereader can do its best.
--- Nathan Bubna <na...@esha.com> wrote:
> Daniel, can you enlighten me on why you ended up
> solving this in the VelocityServlet the way you
> did? i want to port this fix over to the
> VelocityViewServlet, but i gotta admit your solution
> looks ugly to me. i'm assuming there's good
> reason for it, but i can't quite figure it out.
> the solutions we'd discussed earlier in this
> thread still seem clearer to me.
> 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.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org