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 Mon, 16 Jul 2001 01:07:09 GMT
My this is getting combative.... :)

Jonathan Revusky wrote:
> 
> "Geir Magnusson Jr." wrote:
> >
> > Jonathan Revusky wrote:
> > >
> > > "Geir Magnusson Jr." wrote:
> > > >
> > > > Jonathan Revusky wrote:
> > > > >
> > > > > "Geir Magnusson Jr." wrote:
> > > > > > >
> > > > > > > Actually, I missed that the mergeTemplate took the *name*
of the
> > > > > > > template as well. I also just was wondering what the extent
to which
> > > > > > > this had been investigated and tested was.
> > > > > >
> > > > > > Extend to which *what* has been investigated and tested??? 
Is there a
> > > > > > bug?
> > > > >
> > > > > The "what" is using Velocity in locales with other character encodings.
> > > > > I am not reporting a bug. I was asking question or two, but now I
> > > > > understand pretty much completely where things are at, I think.
> > > > >
> > > >
> > > > Just to be clear, for anyone looking at this thread, or finding it in
> > > > the archives -
> > > >
> > > > Velocity works well in locales with non- ISO-8859-1 (latin) character
> > > > encodings.  Of the top of my head, I know that people have used it with
> > > > encodings appropriate for Russian, Japanese, Chinese, French, Spanish
> > > > and Finnish users.
> > >
> > > You should have stopped at Chinese. :-) French, Spanish, and Finnish use
> > > the default ISO-8859-1 (latin) character encoding anyway, so there's no
> > > issue.
> >
> > The spanish was in UTF-8.
> 
> This strikes me as rather odd. AFAIK, the default encoding for a
> Spanish-language locale is ISO-8859-1. I should know. I'm writing you
> from Spain. I often use machines with a Spanish-localized OS. Did
> somebody write, explicitly saying he was storing Spanish-language
> templates in a UTF-8 encoding?

Yes - one of the first examples that we used to test the encoding
support in 1.1 was a UTF-8 containing spanish.

> 
> >
> > > The other ones you mention are interesting to know about though.
> > >
> > > I did not mean to suggest that it didn't work. I have every reason to
> > > believe that it does, since the java I/O libraries are what are
> > > providing the support. It's just a question of knowing where the hooks
> > > are.
> >
> > er, yeah...
> >
> > public Template getTemplate( String template, String encoding)
> 
> I was confused at the moment because there was another API called
> mergeTemplate and I didn't understand it at the moment. I wrote a
> message about that. Though I was a bit fuzzy-headed when I posed the
> question, but that occurs frequently....

Seems to have occurred at the end of this post :)

> Also, it is not as simple as you're suggesting because somebody could
> easily assume (perhaps naively) that if they called getTemplate as above
> with a given encoding, that this would imply that it would be output
> with the same encoding by default. (I know that people should not
> automatically assume this in an ideal world, but still, it is a
> legitimate questions one could ask about this...)

Yes - they are perfectly legitimate questions, and I will go through
that aspects of the docs and improve them in this regard.
 
> None of this is rocket science, mind you, but if you want to develop a
> product for rocket scientists, well, then, be my guest...

?
 
> >
> >
> > > Also, I understand that the input encoding, theoretically, is not
> > > necessarily the same as the output encoding. You could, for example,
> > > store all of the templates in UTF-8 and then output them via the
> > > localized encodings. I was simply expressing doubt that this is very
> > > common in practice. In my own framework, I am currently assuming that
> > > the input and output encodings are the same, since this allows me to
> > > keep my API simpler and hide messy stuff from the end user, which is the
> > > goal. If this turns out to be an issue, I'll revisit it.
> >
> > Ok.  Whatever floats your boat.
> 
> Well, of course. I was my talking about my library and yes, I'll do
> whatever I judge best. Though I could be interested in feedback about
> whether that is the appropriate course. I am not absolutely sure.
> Meanwhile, I have received responses that I find kind of... weird...

I even told you that in my opinion, you were doing a cool thing - if the
user hints at the encoding of the template in the filename, as the
examples you posted showed, then your framework could deduce and 'do the
right thing'.  Other than that, I know nothing about 'Niggle', so I
can't comment.
 
> Look, there is a real issue here where I have the unmistakeable
> impression that you guys have a chip on your shoulders. Okay, Jon
> Stevens obviously does and it's pretty explicit. You, on the other hand,
> are more of a "mailed fist in velvet glove" type. In a way, that's
> actually worse IMO...

Actually, I think I am extremely patient, willing to help anyone who
comes with a legitimate complaint, bug, question, or need for help.  ( I
do tons of support offline from this list with users who for whatever
reason don't want to post problems in public - I once even called a user
on the phone to help them out...)  I am sorry if you found anything
containing attitude in my responses - I will happily go now and review
to make sure I am not out of line.  You yourself might want to do the
same.

I will note that you keep admitting that you were confused and
fuzzy-thinking - all I was trying to do was clear it up for you.  The
encoding support is a relatively new feature, so I wanted to make sure
that it was working well...

In the case of Dr. Cox, I believe he came to us not asking for help,
offering a solution to a problem he found, or even posing a constructive
criticism, but rather, to me anyway, set up an elaborate strawman
regarding his problems configuring Velocity, and then used that to talk
about JAWA.

I don't wish to belabor that thread - I am not happy how it turned out
because I would like to compare and contrast JAWA to Velocity, and have
an intelligent discussion about it, and I know Velocity has things that
could be better.

 
> In the past few days, you guys have received various useful bits of
> feedback -- not from me, but from other people. Examples: The usage of
> the "." as the default location to load templates from is of course
> utterly useless because the current working directory is meaningless in
> the context AFAICS.

Yes - I think that was a pleasant and constructive thread.  As I said
then, in that situation, there is no perfect answer.  Either you use
something like ".", just so that Velocity has something to work from if
you choose not to do any configuration (and that too is something we
thought hard and long about), or you try and use 'root'.  Now, I say
try, because I am not sure what you do for Windows or the Mac.  Unix I
know, but I don't want to be platform specific.  If we went the other
way, using the root of the FS as the template path, then everyone who
expects to specify templates as relative to CWD would be left scratching
their heads... there is no perfect solution here.

and re the CWD - yep - it's useless most of the time in the context of a
web app.  And that's why there is a second servlet example,
servlet_example2 that explicitly shows how you can take care of the
problem.  You would have me dead to rights if there wasn't any docs or
examples...  but there are.

The needs are different for everyone - therefore, just configure the
engine for your application.  We won't tell you what to do, or limit you
from doing what you want to do.

> Or IOW, the default is almost guaranteed to not
> behave in any desirable way. Somebody else pointed out that if you
> specifically give an absolute location for the template file, it doesn't
> work, i.e. some naive user who tries:
> getTemplate("C:\\mytemplates\\mytemplate.html"). Well, that's basically
> a bug. The default code should have the smarts that if you give it an
> absolute path AND the file is there and readable, it should use it. To
> have any other behavior is to willfully waste people's time.

That is nonsense, in my opinion.  For the most common use of velocity,
we never allow two things : starting at root unless specifically
configured, or using '..' in a path for security reasons.

And then what?  Do we have to support the alphabet soup of possibilities
for Window's [broken] file system?   First look at C:, then D:, then E:,
then F:, then... Or do we force people to only use UNC under windows? 
What about the Mac?

Nah, the point of the defaults is to do something simple that works w/o
harm for everyone.

And look at your last sentence - w/o discussion, you just said that we
did this to willfully waste people's time.  I will assume that you meant
something different.

> I agree that it's not good practice to use absolute paths, but there is
> a principle here called "the principle of least surprise" that you are
> failing to follow in the above. In general, Brad Cox was quite right
> that the "ResourceLoader" configuration business is overly complicated.
> It does not particularly surprise me that he had problems getting
> Velocity working. 

Nor me, as he didn't bother to read the manual, look at examples, or ask
any questions.

> The basic rule of thumb is that if 1 person writes you
> saying that, then there are at least 10 other people who had the same
> problem and did not write.

Could be - and my solution is not to make some wacky 'Journey of
Discovery' algorithm flailing about proprietary file systems looking for
something that might be the users intent, but to improve the
documentation, which I will do.

> The criticism that you are making excessive use of static methods to
> vend objects is certainly well founded too, but I would be reluctant to
> press that one too much, since I don't have an easy alternative and I
> tend to use the same pattern in my own code. Still, that critique made
> me think twice about where I was doing that and I will look for better
> ways.

Yep - that's been a long standing one.  And if we can put this thread to
rest satisfactorally so I can move on, I will be checking into the
project whiteboard my solution to make Velocity completely instantiable,
so you can do 

VelocityEngine ve = new VelocityEngine()

w/ no worries.

> 
> In short, Velocity is a pretty good product, but it certainly could be
> better.

Certainly can.  That's why I work on it.

> And really, the fact is, that over the past couple of years lots
> of people have written these HTML template languages for the web.
> Undoubtedly, a number of people wrote template engines as ungraduate
> senior-year projects in a CS program...  Some of the many template
> engines are better than others, but the reason that Velocity has as much
> usage as it does is because of the apache.org linkage. It is not
> particularly due to intrinsic merit.

Thanks for the support.

> 
> This last point I'm making may be considered a gratuitous jab, but
> really, it has a purpose. It is meant to puncture your insufferable
> arrogance. (Also, I'm quite satisfied that the comment is true.)

You are going to have to work harder to do that.  I have been working on
making my arrogance insufferable for years now...  but thanks for the
feedback.

 
> So now, fellas, do be good...
> 
> :-)
> 

After reviewing the posts today, I have to admit I am having a hard time
understanding where this venom is coming from.  From my point of view,
you were struggling with the notion that the encoding of the template
was distinct from and unrelated to the encoding peformed by the output
Writer.  You made some arguements that it something that is commonly
done.  I pointed out that yes, in production practice that is a common
thing, however Velocity still must perform decoding of the input
template to characters, and the input decoding and parsing is completely
separate from the output.

There was a valid suggestion that you made, namely that Velocity should
use the platform default locale encoding rather than a default 8859, and
I agreed, and noted it was due to history...

Other than that, the only thing I got out of this was that I can improve
the documentation surrounding the VelocityServlet convenience class to
get rid of the confusion surrounding getTemplate(), as well as the
Velocity application support class.

Hope you got something out of it...

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