velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <jrevu...@terra.es>
Subject Re: template encodings
Date Mon, 16 Jul 2001 01:48:22 GMT
"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!

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));
}

> What about the Mac?
> 

You're talking out of your hat. The core java libraries deal with this.
The above code snippet also works on the mac or unix.


> 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.

> 
> 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...)

> 
> > 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. 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.

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...

> 
> > 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.

> 
> > 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.

> 
> >
> > 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.

Well, I think you should work on undoing that hard effort.

> 
> 
> > 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.


> 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. 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.

> 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. 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. Your blaming people for not
reading the docs etcetera really shows this. When other people don't get
your stuff working, blame yourself. 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. My getting annoyed at you is
pointless.)

But do fix the thing about the absolute path instead of emitting all
this hot air about proprietary file systems. Cripes!


Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://www.revusky.com/hacks/

Mime
View raw message