velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: template encodings
Date Mon, 16 Jul 2001 02:52:04 GMT
Jonathan Revusky wrote:
> "Geir Magnusson Jr." wrote:
> >
> > 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?
> You're just being argumentative. Your code is broken in this instance.
> This has absolutely nothing to do with cross-platform issues because the
> core java libraries already handle it!

1) Not argumentative. Take my word for it.  I have better things to do
than debate you for the fun of it.

2) The code is not 'broken' as it works as specified and as designed. 
You may disagree with the design constraints we set up, but nonetheless,
it works properly.

3) How would the 'core libraries' handle, as you just suggested, we go
wandering around trying to satisfy the users request....

What if a windows user did

Template t = Velocity.getTemplate("\\templates\\foobar.vm");

then what?  Spin the wheel and choose a letter?  "Today, we choose the
'F:' drive..."

> Specifically in FileResourceLoader.getResourceStream(templateName) you
> should specifically check whether someone has passed in an absolute
> path. Here's the code:
> File f = new File(templateName);
> if (f.isAbsolute() && f.exists()) {
>    return new BufferedInputStream(new FileInputStream(f));
> }

No - like I said - we don't do root unless specifically specified as a
valid template path.  This rule is so popular, WebMacro is going to add
it as well.
> > What about the Mac?
> >
> You're talking out of your hat. 

I would have said "ass".

> The core java libraries deal with this.
> The above code snippet also works on the mac or unix.

Yes, but as I keep trying to tell you, we currently don't let the
FileResourceLoader do this by default.  You can easily make it do that,
by adding root to your valid template paths.

> > Nah, the point of the defaults is to do something simple that works w/o
> > harm for everyone.
> The point is that you have a default that just about never works for
> anybody.

Whatever.  I can't see how you can make such a generalization...
> >
> > 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.
> Yes, I stand by that. Not covering the above case is to willfully waste
> people's time. They put in an absolute filename, they know the file is
> there and is readable and the thing won't find it and they bust their
> ass trying to understand why.
> This is very typical of unix geek mentality, of course. But it is
> basically a willful waste of people's time. (Note that my system of
> choice is still unix...)

Ok.  You are entitled to your opinions.

Just to be clear : I have no investment in the status quo, other than it
was, in my opinion, well thought out and has solid reasons behind the
decisions made in the design.  In fact, other template systems are
changing to mimic those features.  The limit can *easily* be overridden
with a single setProperty() call, so no, this whole argument isn't
really changing my mind.

> >
> > > 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.
> I don't know how much effort he put into it. 

By his own admission, three days, throughout which he didn't read the
manual or ask a question.

> But if more effort is
> required than necessary, you're wasting people's time. As for absolute
> paths being bad practice, then emit a pedantic warning. But the current
> behavior, as well as the error message it emits, is clearly very
> undesirable.

Yes, and we noted that we could do a better log message.
> You're playing dumb here anyway. People only read documentation as a
> last resort anyway. How many times have you downloaded something, mucked
> with it for a while, not got it working and given up? Did you read the
> documentation completely each time? Do you always bother to go to the
> appropriate forum for help? Most people don't. At least most of the
> time. Often, you try something just out of curiosity and you're not
> going to allot that much time...

This is true.  But we can't program to assumptions people will make. 
People have all sorts of different assumptions - more experienced people
will try different approaches than less experienced, people with real
production experience different than academic experience.

Until you and Brad, this really hasn't been a big deal.  

> >
> > > 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.
> You don't need a journey of discovery algorithm for proprietary file
> systems. You're writing in Java. The core libraries handle this. I think
> you know this and you're playing dumb.
> That's annoying.

See example above. Tell me what you do. And don't say "But I put
isAbsolute() in there", because you know that someone will say that they
did put an absolute path "\\template\\foo.vm" and it didn't work and
that our decisions are dumb, and that we are arrogant, and that we are
wasting peoples time, and that they don't want to read the manual, or
ask any questions, that they didn't have time, that...
> >
> > > 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.
> That would be preferable. It seemed to me that you were suggesting that
> there was no problem.

Er, no.  Read the archives. Many of the problems that have been posed
and claimed to be related to this issue turned out to have other
solutions when spun a different way.  

And yes, there are problems where that solution is spot on. Hence the
effort I put into the solution.

The remarkable thing about a community like this is that when you are
too close to a problem (say, like how to configure the
FileResourceLoader to find templates the first time you use it w/o
reading any documentation or README files in the examples) people here
can really be of help to explore other solutions that you didn't think
of (like reading the documentation and README files in the examples).  I
see it all the time, and take advantage of it all the time :)
> >
> > >
> > > 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 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.
> Well, I think you should work on undoing that hard effort.

Whatever.  I want to keep the personal attacks out of this.  You are
free to whack away - I will note you will have to do a better job - at
this point, you are barely bruising the velvet.
> >
> >
> > > 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.
> The reason the mailed fist in the velvet glove guys are harder to deal
> with than the openly nasty guys is that they play the innocent when you
> get openly annoyed at them.

Don't confuse innocense with a concerted attempt at patience.  I am not
playing innocent here - you repeatedly kept confusing the 'use-process'
aspects of encoding (most users use the same encoding as the content
developers) and the technical aspects of how Velocity handles them.  I
thought you had real problems with something, and tried to help. 
Somewhere it went wrong, and now you are in attack mode.  I really don't
want to engage in a battle.  I learned long ago in Usenet that it
doesn't really pay...  its can be an awful lot of fun, but it's
generally like teaching a pig to sing - you waste your time, and annoy
the pig.

I foolishly kept going with the thread to ensure that there was no
confusion with you or any other user following the thread with regards
to Velocity's support of encoding.

> > 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.
> Programmatically, it is, and really, I always knew it was.

However, you wanted to keep the conversation going w/o stating that?  

> In practice,
> it is not really, because, at least to the best of my knowledge, there
> is just about perfect correspondence between the input and output
> encodings. People *could* get confused about this though.

Really?  And how many sites have you developed that gives you such deep
insight into the problem?  

In my case, none.  All have been in America for an American user base.

However, the changes in Velocity were driven by a user at Nokia (they do
some international products, huh?) and a developer who did FOREIGN
LANGUAGE TRAINING via the www.  I took their word for it that indeed,
things needed to be separable.

In fact, version one of encoding support had my naive supposition that
you could just set one encoding for a site.  However, it was quickly and
constructively pointed out to me that that wouldn't fly, and they needed
template by template specification.  And so I made that change,
resulting in the API we have today. 

You can always set a default INPUT_ENCODING if you wish, and Velocity
will respect that, for the simpler sites where there is only one
encoding for the templates.

> > 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...
> No, I get absolutely nothing out of this. My telling you off is a
> complete and utter waste of my time. 

Yes, mainly because I am fairly introspective and am pretty sure that
having had no real problem with you or our original conversation, that
it isn't really deserved.

> I know that (a) I shouldn't bother
> and (b) I'm probably overreacting. I've said all I intend to say. Just
> from this last reply, it is obvious that you have some conceptual issues
> regarding things, at least from my POV.

That was clear from the last post.

> Your blaming people for not
> reading the docs etcetera really shows this. 

Besides Dr. Cox, which I will say again should've spent a few moments
asking questions or reading docs once it didn't work, who have I *ever*
said 'RTFM' to as an answer to an honest question?  I may point to where
in the docs an answer can be found, but I think I have 100% of the time
given a short synopsis of what the solution was....

Give it a whack.  You won't find *one* instance where I berated anyone
for asking a question.

And think this through for a second - this is a *free* as in beer,
*free* as in speech tool that is open for all to take and use with
documentation that has been described as some of the best in the open
source space under a business friendly license.  Many volunteers have
spent a serious amount of time developing Velocity to be the stable,
useful software it is today.

Whats wrong with request that people take a look at documentation? 
People work hard on it, and its there for a reason.

> When other people don't get
> your stuff working, blame yourself.

I do.  And I work hard to fix it.... 

> It may be that the other people are
> being lazy, but you can't change them. (Though in  terms of not being
> able to change other people, I should take that last bit to heart
> myself. There is a kind of recursion here.

I try to make the examples as rich, useful and documented as possible. 
I try to answer every question on the list as fast as I can, because
there is someone there working with Velocity.  And I try to fix things
as fast as possible.

However - I can't be a free psychic consulting service for people that
don't want do look at examples, read docs, or ask questions.  Sometimes
people will come with questions that are obviously in the manual, but
for someone new to web application development, it's a big mess of stuff
to learn at once, and we do everything we can to help.

In the case of Brad Cox, someone who clearly understands computers (to
understate a bit - I mean, he wrote a book on OO in 1986... :), has been
developing sites for 10 years (his claim), and has been sighted on lists
like tomcat-dev advertising JAWA, yes, I personally will not be patient
with his problems - it was clear he wanted to talk about something else.
And he wasn't even asking for help... And it's funny - I wanted to talk
about that something else too...

What is your problem?  I disagree with your claims to how the 'default
directory' should work?  Yes, I disagree.  I have reasons with which I
disagree.  I have been supporting this tool day by day for a long time,
and it hasn't really been a problem.

> My getting annoyed at you is
> pointless.)

It is.


Geir Magnusson Jr.                 
System and Software Consulting
Developing for the web?  See
You have a genius for suggesting things I've come a cropper with!

View raw message