velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: template encodings
Date Sun, 15 Jul 2001 14:25:22 GMT
Jonathan Revusky wrote:
> 
> "Geir Magnusson Jr." wrote:
> >
> > Jonathan Revusky wrote:
> > >
> > > I have the Velocity developer guide doc in front of me and I'm looking
> > > at the section entitled "Template Encoding for Internationalization".
> > >
> > > There is a method called mergeTemplate that takes the encoding as an
> > > argument.
> > >
> > > My belief is that once you figure out the desired locale, and call
> > > response.setLocale(myLocale) that simply by writing to the Writer object
> > > returned by response.getWriter() that it will (should) be encoded
> > > appropriately.
> >
> > I am not sure what you are getting at - but note that the encoding
> > argument to mergeTemplate() is the encoding of the *template*, not the
> > output.  The encoding of the output stream is something else entirely.
> 
> Are you sure you meant to say the above? That mergeTemplate AFAICS is
> clearly used to output. You already have a read pre-parsed template
> object at that stage.
> 

Pretty sure, as I wrote the code... :)

public static boolean mergeTemplate( String templateName, 
                                         Context context, Writer writer
)

public static boolean mergeTemplate( String templateName, String
encoding,
                                      Context context, Writer writer )

mergeTemplate() takes a template name, an encoding [in the second
method] to specify the encoding of the template, a context, and a writer
to output to.

The first version, w/o the encoding argument, is implemented as
        
return mergeTemplate( templateName,
Runtime.getString(INPUT_ENCODING,ENCODING_DEFAULT),
                               context, writer );

so you can see that it will try to get the property INPUT_ENCODING, and
use the Velocuty-provided default if not found.

Note that these two methods have *nothing* to do with servlets at all. 
We don't care *where* in your application the writer comes from...

As for the 'pre-parsed' template, you are confusing it with the 

getTemplate() method, which also has a version that takes an encoding
argument (otherwise uses the default).

When you use the Template object returned by getTemplate(), then you are
right, you have a pre-parsed template and the merge is

template.merge( context, writer );

no encoding needed in either direction, because the template itself is
already converted and parsed, and the writer handles the output
encoding...


> But I think I understand the issue now anyhow.
> 
> It seems to me that this kind of helper method is necessary, since you
> aren't always using velocity from within a servlet engine. That had
> slipped my mind.

It's *always* necessary, even in a servlet engine - you need to declare
the encoding used for the template - template can be in any encoding you
choose to work in.

Again, this encoding has *nothing* to do with output.
 
> >
> > mergetTemplate() is a utility method provided by the Velocity helper
> > class to allow you to easily render a template.  The usual mechanism is
> > to use the pattern of
> >
> > Template t = getTemplate( name, encoding );
> 
> This one, I was not using in my code. Now I have patched it though. I
> assume that a template found via the name_zh_TW.html lookup scheme is
> encoded in the encoding for that locale (Taiwan) which is "Big5". Though
> I don't know how safe an assumption that is.

Not at all.  You have to know the encoding, and specify it.  Velocity
assumes that if you don't specify, the template byte stream (no matter
where it comes from) is encoded in ISO-8859-1

> 
> I don't know whether anybody is using all this structure, since if you
> don't specify a locale, then it's default locale and default encoding
> all ways around, which surely tends to work for unilingual web sites.
> I've tried to go the extra mile in my framework to do the right things
> transparently, but I don't have feedback from people as to whether it
> works for Asian languages etcetera.

Yes, people are using it, and quite effectively.  And it's not even
'default locale'.  It's LATIN-1. :)  People who need and understand it
use it quite well.  The internationalization features was driving by
direct user request.
 
> > t.merge( context, writer);
> 
> This is the method I was using it turns out.

Ah.  See, there is no encoding parameter - because you established the
encoding for the writer if you got it from the response object in a
servlet environment, and you appear to be simply lucky on the input side
:)
 
> >
> > so you see, fundamentally the two steps are distinct.  You could merge
> > the same template repeatedly with different writers that use different
> > encodings, if you wished.
> 
> Yes, that's true, though I don't know if it's really a likely scenario.
> 
> Thanks. When I wrote the note, actually it did slip my mind that
> Velocity might be used in non-servlet contexts, so that does explain the
> separate mergeTemplate helper code.

Actually, that's not why it's there - most people still use the
getTemplate() -> template.merge() pattern in applications... 
getTemplate() still requires you to declare the input encoding of the
template if it is not LATIN-1.

geir

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

Mime
View raw message