You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Jonathan Revusky <jr...@terra.es> on 2001/07/15 13:45:41 UTC
template encodings
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.
IOW, this should really be the realm of responsibility of the underlying
servlet engine AFAICS. (Though, that said, I *think* that extra i18n
hook was added as of the 2.2 servlet spec. I explicitly say that Niggle
requires >2.2 servlet engine.)
This is basically the assumption I have gone on in the Niggle framework.
Funny thing, judging from servlet logs, I get a lot of downloads from
Japan and Taiwan. And they keep coming back when I announce a new
version. But I get no feedback from these people as to whether this
actually works!
In other matters, there is one person who I know to be subscribed to
this list who expressed interest in using Niggle in conjunction with
Velocity. (At the time, only Freemarker and WebMacro were supported.)
There is a preview that allows usage of Velocity as the template engine
available here:
http://revusky.com/dist/niggle1_0_3pre.zip
If you simply read the various references to webmacro and mentally
substitute in velocity, you should be able to get it working with
velocity. There are sample velocity templates for the mini-rolodex
sample app. I will have to patch up the docs before I announce this.
(Probably before mid-week.)
Cheers,
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/
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
>
> Why didn't you use the ClasspathResourceLoader or the jar resource
> loader?
Well, I wanted to have my own code with absolute control. I've received
a couple of messages saying how easy it was. So I thought you were
encouraging me to do it.
I already knew that it was easy! I wrote this code a few days ago.
Jonathan
>
> geir
>
> Jonathan Revusky wrote:
> >
> > Jon Stevens wrote:
> > >
> > > on 7/15/01 5:09 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> > >
> > > > 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.
> > >
> > > No, it is a security hole.
> > >
> > > You don't want some random user to be able to access something like
> > > /etc/passwd or /etc/shadow.
> >
> > Could you explain the mechanism by which a random user would access
> > /etc/passwd because I load a template file from an absolute path?
> >
> > >
> > > Setting a base template path is necessary. Then everything to access the
> > > file is relative to that path and you don't have to worry about people
> > > randomly reading files from that path.
> > >
> > > Go read the bugtraq archives. You will see literally hundreds of security
> > > holes as a result of what you describe.
> > >
> > > This is a very common mistake by newbie software engineers.
> > >
> > > Lastly, it is entirely possible within Velocity for you to come up with your
> > > own ResourceLoader. So, if you don't like the one that comes with Velocity,
> > > then make your own!
> >
> > I already did. Though I am advocating the position of a newbie user, *I*
> > am not at all helpless in this regard. The code below is in the version
> > of Niggle I put up today. It seems fairly reasonable to me. Note that a
> > template is only loaded from an absolute location if the application
> > programmer specifies an absolute location. I encourage people to locate
> > their templates relative to the servlet context classpath.
> >
> > /*
> > Bridge Code to use Velocity template engine with Niggle
> > Copyright (c) 2001, Jonathan Revusky
> > All rights reserved.
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted provided that the following conditions
> > are met:
> >
> > Redistributions of source code must retain the above copyright notice,
> > this list of conditions and the following disclaimer.
> >
> > Redistributions in binary form must reproduce the above copyright
> > notice,
> > this list of conditions and the following disclaimer in the
> > documentation
> > and/or other materials provided with the distribution.
> >
> > The name of Jonathan Revusky may not be used to endorse or promote
> > products derived from this software without specific prior written
> > permission.
> >
> > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> > FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> > COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
> > INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> > SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> > HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> > STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> > IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> > POSSIBILITY OF SUCH DAMAGE.
> > */
> >
> > package com.revusky.niggle.templates.velocityimpl;
> >
> > import org.apache.velocity.exception.ResourceNotFoundException;
> > import org.apache.velocity.runtime.resource.loader.ResourceLoader;
> > import org.apache.velocity.runtime.resource.Resource;
> > import org.apache.commons.collections.ExtendedProperties;
> > import com.revusky.oreo.util.*;
> > import java.io.*;
> > import java.util.*;
> > import java.net.URL;
> >
> > public class CustomResourceLoader extends ResourceLoader {
> >
> > static private ClassLoader classLoader;
> > static private String searchPath;
> >
> > static public void setClassLoader(ClassLoader classLoader) {
> > CustomResourceLoader.classLoader = classLoader;
> > }
> >
> > static public void setSearchPath(String searchPath) {
> > CustomResourceLoader.searchPath = searchPath;
> > }
> >
> > public void init(ExtendedProperties props) {
> > Logger.log("Niggle custom resource loader for Velocity :
> > initialized.", Logger.LOG_INFO);
> > }
> >
> > public InputStream getResourceStream(String name)
> > throws ResourceNotFoundException {
> > try {
> > return findResource(name);
> > } catch (IOException ioe) {
> > }
> > throw new ResourceNotFoundException("Template " + name + " not
> > found");
> > }
> >
> > private InputStream findResource(String name) throws IOException {
> > InputStream is = findAbsolute(name);
> > if (is == null) {
> > is = findOnSearchPath(name);
> > }
> > if (is == null) {
> > is = findOnClassPath(name);
> > }
> > return is;
> > }
> >
> > private InputStream findAbsolute(String name) throws IOException {
> > File f = new File(name);
> > if (f.isAbsolute() && f.canRead()) {
> > fileCache.put(name, f);
> > lastModifiedCache.put(name, new Long(f.lastModified()));
> > return new FileInputStream(f);
> > }
> > else
> > return null;
> > }
> >
> > private InputStream findOnSearchPath(String name) throws IOException
> > {
> > if (searchPath != null) {
> > StringTokenizer st = new StringTokenizer(searchPath,
> > File.pathSeparator);
> > while (st.hasMoreTokens()) {
> > String path = st.nextToken();
> > if (path.endsWith("/") || path.endsWith("\\")) {
> > path = path.substring(0, path.length() -1);
> > }
> > String filename = path + "/" + name;
> > InputStream is = findAbsolute(filename);
> > if (is == null) {
> > is = findOnClassPath(filename);
> > }
> > if (is != null) {
> > return is;
> > }
> > }
> > }
> > return null;
> > }
> >
> > private InputStream findOnClassPath(String name) throws IOException
> > {
> > URL url = classLoader.getResource(name);
> > if (url == null) {
> > url = ClassLoader.getSystemResource(name);
> > }
> > if (url == null) {
> > return null;
> > }
> > String filename = url.getFile();
> > if (filename.startsWith("file:")) {
> > filename = filename.substring(5);
> > }
> > File f = new File(filename);
> > if (f.exists()) {
> > fileCache.put(name, f);
> > lastModifiedCache.put(name, new Long(f.lastModified()));
> > }
> > else
> > fileCache.put(name, null);
> > return url.openStream();
> > }
> >
> > public boolean isSourceModified(Resource res) {
> > String name = res.getName();
> > if (fileCache.containsKey(name)) {
> > File f = (File) fileCache.get(name);
> > if (f == null) {
> > return false;
> > }
> > else {
> > long l = f.lastModified();
> > Long L = (Long) lastModifiedCache.get(name);
> > return (L!=null) && (L.longValue() < l);
> > }
> > }
> > return false;
> > }
> >
> > public long getLastModified(Resource res) {
> > String name = res.getName();
> > Long L = (Long) lastModifiedCache.get(name);
> > if (L!= null) {
> > return L.longValue();
> > }
> > return 0L;
> > }
> >
> > private Map fileCache = Collections.synchronizedMap(new HashMap());
> > private Map lastModifiedCache = Collections.synchronizedMap(new
> > HashMap());
> > }
>
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Why didn't you use the ClasspathResourceLoader or the jar resource
loader?
geir
Jonathan Revusky wrote:
>
> Jon Stevens wrote:
> >
> > on 7/15/01 5:09 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> >
> > > 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.
> >
> > No, it is a security hole.
> >
> > You don't want some random user to be able to access something like
> > /etc/passwd or /etc/shadow.
>
> Could you explain the mechanism by which a random user would access
> /etc/passwd because I load a template file from an absolute path?
>
> >
> > Setting a base template path is necessary. Then everything to access the
> > file is relative to that path and you don't have to worry about people
> > randomly reading files from that path.
> >
> > Go read the bugtraq archives. You will see literally hundreds of security
> > holes as a result of what you describe.
> >
> > This is a very common mistake by newbie software engineers.
> >
> > Lastly, it is entirely possible within Velocity for you to come up with your
> > own ResourceLoader. So, if you don't like the one that comes with Velocity,
> > then make your own!
>
> I already did. Though I am advocating the position of a newbie user, *I*
> am not at all helpless in this regard. The code below is in the version
> of Niggle I put up today. It seems fairly reasonable to me. Note that a
> template is only loaded from an absolute location if the application
> programmer specifies an absolute location. I encourage people to locate
> their templates relative to the servlet context classpath.
>
> /*
> Bridge Code to use Velocity template engine with Niggle
> Copyright (c) 2001, Jonathan Revusky
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
>
> Redistributions of source code must retain the above copyright notice,
> this list of conditions and the following disclaimer.
>
> Redistributions in binary form must reproduce the above copyright
> notice,
> this list of conditions and the following disclaimer in the
> documentation
> and/or other materials provided with the distribution.
>
> The name of Jonathan Revusky may not be used to endorse or promote
> products derived from this software without specific prior written
> permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
> INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
> */
>
> package com.revusky.niggle.templates.velocityimpl;
>
> import org.apache.velocity.exception.ResourceNotFoundException;
> import org.apache.velocity.runtime.resource.loader.ResourceLoader;
> import org.apache.velocity.runtime.resource.Resource;
> import org.apache.commons.collections.ExtendedProperties;
> import com.revusky.oreo.util.*;
> import java.io.*;
> import java.util.*;
> import java.net.URL;
>
> public class CustomResourceLoader extends ResourceLoader {
>
> static private ClassLoader classLoader;
> static private String searchPath;
>
> static public void setClassLoader(ClassLoader classLoader) {
> CustomResourceLoader.classLoader = classLoader;
> }
>
> static public void setSearchPath(String searchPath) {
> CustomResourceLoader.searchPath = searchPath;
> }
>
> public void init(ExtendedProperties props) {
> Logger.log("Niggle custom resource loader for Velocity :
> initialized.", Logger.LOG_INFO);
> }
>
> public InputStream getResourceStream(String name)
> throws ResourceNotFoundException {
> try {
> return findResource(name);
> } catch (IOException ioe) {
> }
> throw new ResourceNotFoundException("Template " + name + " not
> found");
> }
>
> private InputStream findResource(String name) throws IOException {
> InputStream is = findAbsolute(name);
> if (is == null) {
> is = findOnSearchPath(name);
> }
> if (is == null) {
> is = findOnClassPath(name);
> }
> return is;
> }
>
> private InputStream findAbsolute(String name) throws IOException {
> File f = new File(name);
> if (f.isAbsolute() && f.canRead()) {
> fileCache.put(name, f);
> lastModifiedCache.put(name, new Long(f.lastModified()));
> return new FileInputStream(f);
> }
> else
> return null;
> }
>
> private InputStream findOnSearchPath(String name) throws IOException
> {
> if (searchPath != null) {
> StringTokenizer st = new StringTokenizer(searchPath,
> File.pathSeparator);
> while (st.hasMoreTokens()) {
> String path = st.nextToken();
> if (path.endsWith("/") || path.endsWith("\\")) {
> path = path.substring(0, path.length() -1);
> }
> String filename = path + "/" + name;
> InputStream is = findAbsolute(filename);
> if (is == null) {
> is = findOnClassPath(filename);
> }
> if (is != null) {
> return is;
> }
> }
> }
> return null;
> }
>
> private InputStream findOnClassPath(String name) throws IOException
> {
> URL url = classLoader.getResource(name);
> if (url == null) {
> url = ClassLoader.getSystemResource(name);
> }
> if (url == null) {
> return null;
> }
> String filename = url.getFile();
> if (filename.startsWith("file:")) {
> filename = filename.substring(5);
> }
> File f = new File(filename);
> if (f.exists()) {
> fileCache.put(name, f);
> lastModifiedCache.put(name, new Long(f.lastModified()));
> }
> else
> fileCache.put(name, null);
> return url.openStream();
> }
>
> public boolean isSourceModified(Resource res) {
> String name = res.getName();
> if (fileCache.containsKey(name)) {
> File f = (File) fileCache.get(name);
> if (f == null) {
> return false;
> }
> else {
> long l = f.lastModified();
> Long L = (Long) lastModifiedCache.get(name);
> return (L!=null) && (L.longValue() < l);
> }
> }
> return false;
> }
>
> public long getLastModified(Resource res) {
> String name = res.getName();
> Long L = (Long) lastModifiedCache.get(name);
> if (L!= null) {
> return L.longValue();
> }
> return 0L;
> }
>
> private Map fileCache = Collections.synchronizedMap(new HashMap());
> private Map lastModifiedCache = Collections.synchronizedMap(new
> HashMap());
> }
--
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Jon Stevens wrote:
>
> on 7/15/01 5:09 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > 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.
>
> No, it is a security hole.
>
> You don't want some random user to be able to access something like
> /etc/passwd or /etc/shadow.
Could you explain the mechanism by which a random user would access
/etc/passwd because I load a template file from an absolute path?
>
> Setting a base template path is necessary. Then everything to access the
> file is relative to that path and you don't have to worry about people
> randomly reading files from that path.
>
> Go read the bugtraq archives. You will see literally hundreds of security
> holes as a result of what you describe.
>
> This is a very common mistake by newbie software engineers.
>
> Lastly, it is entirely possible within Velocity for you to come up with your
> own ResourceLoader. So, if you don't like the one that comes with Velocity,
> then make your own!
I already did. Though I am advocating the position of a newbie user, *I*
am not at all helpless in this regard. The code below is in the version
of Niggle I put up today. It seems fairly reasonable to me. Note that a
template is only loaded from an absolute location if the application
programmer specifies an absolute location. I encourage people to locate
their templates relative to the servlet context classpath.
/*
Bridge Code to use Velocity template engine with Niggle
Copyright (c) 2001, Jonathan Revusky
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright
notice,
this list of conditions and the following disclaimer in the
documentation
and/or other materials provided with the distribution.
The name of Jonathan Revusky may not be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
*/
package com.revusky.niggle.templates.velocityimpl;
import org.apache.velocity.exception.ResourceNotFoundException;
import org.apache.velocity.runtime.resource.loader.ResourceLoader;
import org.apache.velocity.runtime.resource.Resource;
import org.apache.commons.collections.ExtendedProperties;
import com.revusky.oreo.util.*;
import java.io.*;
import java.util.*;
import java.net.URL;
public class CustomResourceLoader extends ResourceLoader {
static private ClassLoader classLoader;
static private String searchPath;
static public void setClassLoader(ClassLoader classLoader) {
CustomResourceLoader.classLoader = classLoader;
}
static public void setSearchPath(String searchPath) {
CustomResourceLoader.searchPath = searchPath;
}
public void init(ExtendedProperties props) {
Logger.log("Niggle custom resource loader for Velocity :
initialized.", Logger.LOG_INFO);
}
public InputStream getResourceStream(String name)
throws ResourceNotFoundException {
try {
return findResource(name);
} catch (IOException ioe) {
}
throw new ResourceNotFoundException("Template " + name + " not
found");
}
private InputStream findResource(String name) throws IOException {
InputStream is = findAbsolute(name);
if (is == null) {
is = findOnSearchPath(name);
}
if (is == null) {
is = findOnClassPath(name);
}
return is;
}
private InputStream findAbsolute(String name) throws IOException {
File f = new File(name);
if (f.isAbsolute() && f.canRead()) {
fileCache.put(name, f);
lastModifiedCache.put(name, new Long(f.lastModified()));
return new FileInputStream(f);
}
else
return null;
}
private InputStream findOnSearchPath(String name) throws IOException
{
if (searchPath != null) {
StringTokenizer st = new StringTokenizer(searchPath,
File.pathSeparator);
while (st.hasMoreTokens()) {
String path = st.nextToken();
if (path.endsWith("/") || path.endsWith("\\")) {
path = path.substring(0, path.length() -1);
}
String filename = path + "/" + name;
InputStream is = findAbsolute(filename);
if (is == null) {
is = findOnClassPath(filename);
}
if (is != null) {
return is;
}
}
}
return null;
}
private InputStream findOnClassPath(String name) throws IOException
{
URL url = classLoader.getResource(name);
if (url == null) {
url = ClassLoader.getSystemResource(name);
}
if (url == null) {
return null;
}
String filename = url.getFile();
if (filename.startsWith("file:")) {
filename = filename.substring(5);
}
File f = new File(filename);
if (f.exists()) {
fileCache.put(name, f);
lastModifiedCache.put(name, new Long(f.lastModified()));
}
else
fileCache.put(name, null);
return url.openStream();
}
public boolean isSourceModified(Resource res) {
String name = res.getName();
if (fileCache.containsKey(name)) {
File f = (File) fileCache.get(name);
if (f == null) {
return false;
}
else {
long l = f.lastModified();
Long L = (Long) lastModifiedCache.get(name);
return (L!=null) && (L.longValue() < l);
}
}
return false;
}
public long getLastModified(Resource res) {
String name = res.getName();
Long L = (Long) lastModifiedCache.get(name);
if (L!= null) {
return L.longValue();
}
return 0L;
}
private Map fileCache = Collections.synchronizedMap(new HashMap());
private Map lastModifiedCache = Collections.synchronizedMap(new
HashMap());
}
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
No mas :)
Tal Dayan wrote:
>
> Is it true that this would be a security hole only when the users
> (the ones at the browsers, not the programmers or the designers)
> can specify a path to a template ?
I wouldn't say only - that requires a precience that I personally don't
have. I would assume that there are other ways, not intended, for it to
happen.
> We are using velocity from and application that uses few hard coded
> template names. Is it still a security risk ?
Generally not. However, I assume that you are also specifying the
sources for the templates?
> Also, to solve the first-time-use-out-of-the-box-experience, a detailed
> message that specifies that the template was not found at x, y, z
> and how the path can be changed may be useful.
It's possible. The only issue is balancing that versus keeping crap out
of the logs, which can be dealt with using switches, I suppose. So
here's a question - how many apps do a search/fail approach? For
example, I have seen uses where the app walks down/up a tree finding the
first place a template lives, so you can layer a base template set
underneath customized pieces... those kinds of users wouldn't want the
blather, but its true that since they seem to be the minority, we can
make them shut it off....
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!
RE: template encodings
Posted by Tal Dayan <ta...@zapta.com>.
Is it true that this would be a security hole only when the users
(the ones at the browsers, not the programmers or the designers)
can specify a path to a template ?
We are using velocity from and application that uses few hard coded
template names. Is it still a security risk ?
Also, to solve the first-time-use-out-of-the-box-experience, a detailed
message that specifies that the template was not found at x, y, z
and how the path can be changed may be useful.
Thanks,
Tal
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Monday, July 16, 2001 12:54 PM
> To: velocity-user
> Subject: Re: template encodings
>
>
> on 7/15/01 5:09 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > 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.
>
> No, it is a security hole.
>
> You don't want some random user to be able to access something like
> /etc/passwd or /etc/shadow.
>
> Setting a base template path is necessary. Then everything to access the
> file is relative to that path and you don't have to worry about people
> randomly reading files from that path.
>
> Go read the bugtraq archives. You will see literally hundreds of security
> holes as a result of what you describe.
>
> This is a very common mistake by newbie software engineers.
>
> Lastly, it is entirely possible within Velocity for you to come
> up with your
> own ResourceLoader. So, if you don't like the one that comes with
> Velocity,
> then make your own! However, we will not be shipping a product with known
> security holes in it.
>
> thanks.
>
> -jon
>
>
Re: template encodings
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/15/01 5:09 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> 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.
No, it is a security hole.
You don't want some random user to be able to access something like
/etc/passwd or /etc/shadow.
Setting a base template path is necessary. Then everything to access the
file is relative to that path and you don't have to worry about people
randomly reading files from that path.
Go read the bugtraq archives. You will see literally hundreds of security
holes as a result of what you describe.
This is a very common mistake by newbie software engineers.
Lastly, it is entirely possible within Velocity for you to come up with your
own ResourceLoader. So, if you don't like the one that comes with Velocity,
then make your own! However, we will not be shipping a product with known
security holes in it.
thanks.
-jon
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
>
> 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.
Well, your behavior suggests otherwise. If you did have better things to
do, you'd be doing them.
>
> 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.
There is no condition under which the default behavior makes any sense.
Furthermore, it is defined in such a way that it will inevitably confuse
people. To me, that qualifies as "broken".
>
> 3) How would the 'core libraries' handle, as you just suggested, we go
> wandering around trying to satisfy the users request....
Straw man. I did not suggest that you go "wandering around". I said
specifically that if somebody gives a fully specified filename and the
file is present, the template engine should use it!
If you downloaded an XML parser and stuck a file in your file system
called: /home/geir/test/somefile.xml
and you wrote code saying:
XMLParser.parse("/home/geir/test/somefile.xml");
and said file exists, then I believe that it should really parse that
file. It should not (at least as a default behavior) second-guess
whether you really mean to parse that file! At least that should be the
default behavior! To define a *default* behavior that is different from
the above will *inevitably* create a situation that confuses people.
>
> 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..."
No, because that's not an absolute file location. In Windows-land, an
*absolute* file location starts with C:\ or D:\ or something like that.
I would just go with the File.isAbsolute() call in the core java API's.
In the above case, it would return false. The next logical thing for Mr.
Newbie to try would be to specify the drive letter as well and then,
voila, it would work. But if a newbie user specifies the file location
as completely as is possible and the engine does not load the file, this
will cause frustration and confusion.
>
> >
> > 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.
I know that's what you do. I am suggesting that the default behavior is
wrong.
> 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.
Yes, but if I'm a newbie, I have to know where the config entry is
etcetera. I have to muck around a bit. I am specifically talking about
having out-of-the-box defaults such that a new user will get going as
quickly as possible.
I don't have any stake in this, because I have already written a
CustomResourceLoader that Niggle uses in conjunction with Velocity that
has a default policy that IMO makes more sense.
As for the comments below (snipped) about your history of participation,
okay, I take your word for it. In any case, it is right and proper that
you take pride in your hard work, but my perception is that there is an
extreme resistance to being told things.
If you guys really have pride and confidence in your work, then you
shouldn't need to be so on the defensive.
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/
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Rian Schmidt wrote:
>
> OK, well, I'll speak up for the lurker community. I really like Velocity.
> I am trying to integrate it into a new product, and so I subscribe to this
> mailing list so that I can read all the tips and information that pass
> through. So, I read almost all of the traffic.
>
> As I'm sure you guys are aware, the last couple of days have been really
> voluminous and dumb. Maybe when someone shows up to sell their own approach
> (without having done even the minimum of research as far as I could tell) or
> you get offended with someone's (reasonable or not) insistence that a
> "feature" is really a "bug," you could engage them in email if you feel the
> need? Or just acknowledge or ignore the comment and drop it?
>
> It's just a request; I'm going to continue to use Velocity in any case, but
> I'd like to be able to continue following the threads on the mailing list
> without wanting to slap someone on the back of the head.
Rian,
I definitely overreacted. It was very hot and humid here and I felt like
I was being needled a bit. Maybe I was imagining things. I think that
there is an issue where the Velocity developers seem to have some kind
of chip on their shoulders. I did not even say initially that anything
about the template encodings was a bug or that it didn't work properly.
I was simply making some fuzzy comments and I seemed to elicit this
defensive reaction.
In general, this idea that everybody should have read all the docs or
something is misguided and should not be encouraged.
But I did overreact. I was lurking and found some of the stuff annoying
too, and then (since human nature is perverse) I contributed to it.
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rian Schmidt wrote:
>
> OK, well, I'll speak up for the lurker community. I really like Velocity.
> I am trying to integrate it into a new product, and so I subscribe to this
> mailing list so that I can read all the tips and information that pass
> through. So, I read almost all of the traffic.
>
> As I'm sure you guys are aware, the last couple of days have been really
> voluminous and dumb. Maybe when someone shows up to sell their own approach
> (without having done even the minimum of research as far as I could tell) or
> you get offended with someone's (reasonable or not) insistence that a
> "feature" is really a "bug," you could engage them in email if you feel the
> need? Or just acknowledge or ignore the comment and drop it?
I assume this is aimed at me :)
Honestly, I am open to anyone selling their own approach - that is the
way that we all learn about new stuff and how this space grows and
develops. What got my goat was how it was done, but I won't belabor it
(again) here.
Again, I would really enjoy a discussion about JAWA and any other
templating solution here in this forum if others would be tolerant of
the obvious off-topic nature. Maybe I will do an OOB invitation to Brad
for that if no one minds.
The funny part of the feature/bug thing was that the thread had nothing
to do with it until the end...
>
> It's just a request; I'm going to continue to use Velocity in any case, but
> I'd like to be able to continue following the threads on the mailing list
> without wanting to slap someone on the back of the head.
:)
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!
Re: template encodings
Posted by Rian Schmidt <ri...@finebrand.com>.
OK, well, I'll speak up for the lurker community. I really like Velocity.
I am trying to integrate it into a new product, and so I subscribe to this
mailing list so that I can read all the tips and information that pass
through. So, I read almost all of the traffic.
As I'm sure you guys are aware, the last couple of days have been really
voluminous and dumb. Maybe when someone shows up to sell their own approach
(without having done even the minimum of research as far as I could tell) or
you get offended with someone's (reasonable or not) insistence that a
"feature" is really a "bug," you could engage them in email if you feel the
need? Or just acknowledge or ignore the comment and drop it?
It's just a request; I'm going to continue to use Velocity in any case, but
I'd like to be able to continue following the threads on the mailing list
without wanting to slap someone on the back of the head.
Rian
----- Original Message -----
From: Geir Magnusson Jr. <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
Sent: Sunday, July 15, 2001 7:52 PM
Subject: Re: template encodings
> 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 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.
>
> 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....
>
> http://www.mail-archive.com/
>
> 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
>
> --
> 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!
>
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
> > > 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?
I believed that to be clear. From my POV, I thought it was obvious that
I knew that the input stream that you read a raw template from and the
output stream that you send the cooked output to are two different
streams and could have different encodings. I simply expressed doubt
that, in practice, they ever are different encodings.
Now, I was not in a good mood and it was very hot and humid and I
thought you were doing some passive-aggressive thing of suggesting that
I was being dim.
It was probably my imagination and I'm sorry I reacted the way I did.
I'll try to respond constructively below.
>
> > 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?
I have done plenty of web development, but only in Western European
languages, and they all use the same character encoding. I believe I
stated that.
OTOH, I am known in certain circles for writing software that really
"just works". I have a sixth sense for the kinds of mistakes people will
make and I think very hard about how to design things in such a way that
those mistakes aren't possible.
IMO, it would be very easy for somebody to assume that the output stream
is automatically in the same encoding as the input stream. It's just a
very natural kind of mistake people would make.
When I first subscibed to this list (or maybe that was webmacro, I don't
remember) somebody was in fact having some issue about Chinese
characters and it is entirely possible that it was this exact mistake.
> In my case, none. All have been in America for an American user base.
Well, that's no crime.
>
> 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.
That assumption is built into Freemarker, for example. I actually
implemented a LocalizedTemplate that subclasses
freemarker.template.Template that takes an explicit encoding in the
constrcutor. However, in the last day, I realized something. I realized
that my class is broken wrt includes. The #included templates will
revert to the platform default encoding. The includes issue had not
occurred to me and I guess this can only be addressed with the help of
the freemarker people. I'm going to look at webmacro next.
I then looked at the Velocity code and realized that you are taking this
into account. The #included templates do get the encoding of the parent.
I see the necessary hook in
org.apache.velocity.context.InternalHousekeepingContext. So I
congratulate you on a thorough job.
Though, OTOH, is it impossible that someone would want to #include a
file stored in a different encoding??? Somebody *could* have a Japanese
file and #include some English text stored in the Latin-1 encoding...
Maybe #include should have an optional second argument that takes the
encoding. (Though obviously the default should be to read the #include
in the same encoding as the enclosing template.)
> 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.
Yes, I understand that. The interesting case is if you run a
multilingual site where the character encodings differ.
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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 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.
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....
http://www.mail-archive.com/
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
--
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!
Re: template encodings
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/16/01 6:04 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> I tend to give people benefit of the doubt.
Maybe you can realize that we have been trying to provide an excellent tool
and that it may not have lived up to your (stupid) expectations that it
always kiss your ass when you open it up and use it.
-jon
RE: Sick of pointless arguments on this list WAS: template encodings
Posted by Paulo Gaspar <pa...@krankikom.de>.
Cool down Jonathan:
You do not have to agree with "us" and "we" do not have to agree with you.
This list supports multiple opinions!
=;o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
>
> "Geir Magnusson Jr." wrote:
> >
> > Does this mean I can't respond to the last message from Jonathan? :)
>
> You don't need to, Geir. I've slept on it and I've decided that you guys
> are right.
>
> template = Velocity.getTemplate("C:\\mytemplates\\mysillytemplate");
>
> should not work out-of-the-box. People should have to read the
> documentation and figure out how to change the configuration. After all,
> if people could get it working without reading docs at all, then all the
> hard work you put into the documentation would be wasted!
>
> But more importantly, things should not work too easily for people. You
> see, though some people may not realize it, the goal of software
> development is not really to develop software. That is merely a side
> effect. The goal is really to build character. If things work too
> easily, then people get lazy. On the other hand, when things are more
> difficult and they have to figure out configuration files and things to
> get a simple example working, they suffer a little bit, and that's
> character-building.
>
> Also, letting people read a template file from an absolute path is a
> security hole. I am still not sure why, but you've said it enough times,
> and you're really smart guys, so I'm convinced that it must be true. You
> may not see much of me for a while. I will probably be on various
> discussion lists for libraries with API's that can take an absolute
> filename as an argument. I will be spreading the word that this is a
> huge security risk in and of itself and that these libraries should have
> the same defaults as Velocity.
>
> >
> > 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!
>
> --
> 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/
>
Re: Sick of pointless arguments on this list WAS: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
>
> Does this mean I can't respond to the last message from Jonathan? :)
You don't need to, Geir. I've slept on it and I've decided that you guys
are right.
template = Velocity.getTemplate("C:\\mytemplates\\mysillytemplate");
should not work out-of-the-box. People should have to read the
documentation and figure out how to change the configuration. After all,
if people could get it working without reading docs at all, then all the
hard work you put into the documentation would be wasted!
But more importantly, things should not work too easily for people. You
see, though some people may not realize it, the goal of software
development is not really to develop software. That is merely a side
effect. The goal is really to build character. If things work too
easily, then people get lazy. On the other hand, when things are more
difficult and they have to figure out configuration files and things to
get a simple example working, they suffer a little bit, and that's
character-building.
Also, letting people read a template file from an absolute path is a
security hole. I am still not sure why, but you've said it enough times,
and you're really smart guys, so I'm convinced that it must be true. You
may not see much of me for a while. I will probably be on various
discussion lists for libraries with API's that can take an absolute
filename as an argument. I will be spreading the word that this is a
huge security risk in and of itself and that these libraries should have
the same defaults as Velocity.
>
> 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!
--
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/
RE: Sick of pointless arguments on this list WAS: template encodings
Posted by David Rees <dr...@ebetinc.com>.
> -----Original Message-----
> From: gmj@mta2.srv.hcvlny.cv.net [mailto:gmj@mta2.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
>
> Does this mean I can't respond to the last message from Jonathan? :)
One more message can't hurt. ;-)
-Dave
Re: Sick of pointless arguments on this list WAS: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Rees wrote:
>
> > -----Original Message-----
> > From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> > Jonathan Revusky
> >
> > Jon Stevens wrote:
> > >
> > > on 7/16/01 4:35 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> > >
> > > > Well, you do seem argumentative, Geir.
> > >
> > > He is being argumentative in response to you being a complete asshole.
> >
> > Not a good strategy. If somebody is being a complete asshole, it's
> > better just to say that they have good ideas, and you'll take it into
> > account and that you appreciate the feedback...
>
> Ugh,
>
> Why do threads on this list always seem to turn into some sort of ego
> bashing nightmare? They seem to turn up every couple days. All it does is
> add countless messages for me to delete while trying to sift through the
> good stuff.
>
> Why don't you guys take your ego-bashing off list and save the rest of us
> from your fights? I want to learn about Velocity, not who's the biggest
> asshole.
>
Does this mean I can't respond to the last message from Jonathan? :)
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!
Sick of pointless arguments on this list WAS: template encodings
Posted by David Rees <dr...@ebetinc.com>.
> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
> Jon Stevens wrote:
> >
> > on 7/16/01 4:35 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> >
> > > Well, you do seem argumentative, Geir.
> >
> > He is being argumentative in response to you being a complete asshole.
>
> Not a good strategy. If somebody is being a complete asshole, it's
> better just to say that they have good ideas, and you'll take it into
> account and that you appreciate the feedback...
Ugh,
Why do threads on this list always seem to turn into some sort of ego
bashing nightmare? They seem to turn up every couple days. All it does is
add countless messages for me to delete while trying to sift through the
good stuff.
Why don't you guys take your ego-bashing off list and save the rest of us
from your fights? I want to learn about Velocity, not who's the biggest
asshole.
-Dave
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Jon Stevens wrote:
>
> on 7/16/01 4:35 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > Well, you do seem argumentative, Geir.
>
> He is being argumentative in response to you being a complete asshole.
Not a good strategy. If somebody is being a complete asshole, it's
better just to say that they have good ideas, and you'll take it into
account and that you appreciate the feedback...
Works far better...
>
> I really don't see a problem with that.
Well, I guess that's a truly important fact, seeing as how you are the
moral and ethical compass of the entire fucking world.
>
> > (You don't know me, I know, but I really am a very strong java
> > developer, you know... I do understand this stuff! :-))
>
> So far, I haven't seen any evidence to suggest that as being true.
Well, if you want to go look, go download some of my code and look at
it. I don't really have any feeling that I have to prove anything to
you.
And in general, I don't go around thinking anybody has to prove anything
to me. I tend to give people benefit of the doubt. And in general, I try
not to go around behaving like some kind of complete and utter fucking
prima donna.
To paraphrase Bob Dylan on (or shortly after) his 60th birthday:
"
You may be a hair-dresser,
know how to cut hair...
You may have written a template engine,
but not many people care...
"
>
> p.s. Next time you are out in Berkeley, California, I would be happy to buy
> you dinner and a drink. I'm sure you are a nice guy in person.
Oh, thanks. :-) I might take you up on that. Out of curiosity...
>
> -jon
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/
Re: template encodings
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/16/01 4:35 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> Well, you do seem argumentative, Geir.
He is being argumentative in response to you being a complete asshole.
I really don't see a problem with that.
> (You don't know me, I know, but I really am a very strong java
> developer, you know... I do understand this stuff! :-))
So far, I haven't seen any evidence to suggest that as being true.
p.s. Next time you are out in Berkeley, California, I would be happy to buy
you dinner and a drink. I'm sure you are a nice guy in person.
-jon
RE: template encodings
Posted by Paulo Gaspar <pa...@krankikom.de>.
Geir is right!
=;o)
Paulo
> -----Original Message-----
> From: gmj@mta2.srv.hcvlny.cv.net [mailto:gmj@mta2.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Tuesday, July 17, 2001 12:00 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: template encodings
>
>
> Jon Stevens wrote:
> >
> > on 7/16/01 5:48 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> >
> > > The security issues don't matter if somebody is just trying to get
> > > Hello, World to work.
> >
> > Now that is funny.
> >
> > That is like saying that all Unix boxes should come with a root
> user with a
> > well known password.
>
> No, with no password, because as Joe Newbie, the well-known password
> wouldn't be known to you, and you would have to read it in the manual...
>
> 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!
>
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 7/16/01 5:48 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > The security issues don't matter if somebody is just trying to get
> > Hello, World to work.
>
> Now that is funny.
>
> That is like saying that all Unix boxes should come with a root user with a
> well known password.
No, with no password, because as Joe Newbie, the well-known password
wouldn't be known to you, and you would have to read it in the manual...
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!
RE: template encodings
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Really, you know, in the above, you are writing something pretty STUPID,
> making a STUPID analogy in an aborted, childish attempt to make *me*
> look stupid.
Jon always does that (I should know).
But I am not so sure on how aborted the attempt was.
> I shouldn't rise to this ...
You are right on that one.
Couldn't resist 'cause I'm just human,
Paulo
> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
>
> Jon Stevens wrote:
> >
> > on 7/16/01 5:48 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> >
> > > The security issues don't matter if somebody is just trying to get
> > > Hello, World to work.
> >
> > Now that is funny.
> >
> > That is like saying that all Unix boxes should come with a root
> user with a
> > well known password.
>
> I shouldn't rise to this, but that comparison is ridiculous!
>
> Password-protected root access is specifically one of the various layers
> of security that a unix OS provides.
>
> There are various other layers as well, in terms of the priveleges of
> various users, etcetera. Java itself, via the
> ClassLoader/SecurityManager API's, has very fine-grained security
> options on top of this.
>
> Velocity, OTOH, is a template processing engine. It exists to process
> templates. It is not part of the various layers of security. If you give
> it an absolute path and and the file is present and readable, AFAICS, it
> should process it, because this is not code that is operating at a level
> where it should second-guess whether somebody really should be allowed
> to read a file.
>
> Is there any more reason for Velocity, in its default configuration, to
> refuse to process a template file passed in via an absolute filename
> than, say, for an XML parsing API to refuse to parse a file passed in
> via an absolute path? Because of security reasons??!!
>
> Really, you know, in the above, you are writing something pretty STUPID,
> making a STUPID analogy in an aborted, childish attempt to make *me*
> look stupid.
>
> >
> > -jon
>
> --
> Jonathan Revusky
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Jon Stevens wrote:
>
> on 7/16/01 5:48 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > The security issues don't matter if somebody is just trying to get
> > Hello, World to work.
>
> Now that is funny.
>
> That is like saying that all Unix boxes should come with a root user with a
> well known password.
I shouldn't rise to this, but that comparison is ridiculous!
Password-protected root access is specifically one of the various layers
of security that a unix OS provides.
There are various other layers as well, in terms of the priveleges of
various users, etcetera. Java itself, via the
ClassLoader/SecurityManager API's, has very fine-grained security
options on top of this.
Velocity, OTOH, is a template processing engine. It exists to process
templates. It is not part of the various layers of security. If you give
it an absolute path and and the file is present and readable, AFAICS, it
should process it, because this is not code that is operating at a level
where it should second-guess whether somebody really should be allowed
to read a file.
Is there any more reason for Velocity, in its default configuration, to
refuse to process a template file passed in via an absolute filename
than, say, for an XML parsing API to refuse to parse a file passed in
via an absolute path? Because of security reasons??!!
Really, you know, in the above, you are writing something pretty STUPID,
making a STUPID analogy in an aborted, childish attempt to make *me*
look stupid.
>
> -jon
--
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/
Re: template encodings
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/16/01 5:48 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> The security issues don't matter if somebody is just trying to get
> Hello, World to work.
Now that is funny.
That is like saying that all Unix boxes should come with a root user with a
well known password.
-jon
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Jon Stevens wrote:
>
> on 7/17/01 10:05 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>
> > I suspect that stuff like this happened often before I ever
> > subscribed.
>
> Nope. You win. You are the first major asshole to subscribe to this list
> (other than myself <smile>). :-)
I'm deconstructing this...
Actually, I guess it must be a complement. Correctly or not, you surely
have a high opinion of yourself and thus, if you are comparing me to
you, then logically... it must be meant as flattery.
So, thank you...
I don't know how much we have in common. Probably one thing: I don't
tend to take shit from people.
>
> Go read the archives if you don't believe me.
My initial reaction is to not believe you, I'm skeptical, but I'm not
interested enough to search the archives. So I'll just maintain
agnosticism.
>
> -jon
--
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/
Re: template encodings
Posted by Jon Stevens <jo...@latchkey.com>.
on 7/17/01 10:05 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
> I suspect that stuff like this happened often before I ever
> subscribed.
Nope. You win. You are the first major asshole to subscribe to this list
(other than myself <smile>). :-)
Go read the archives if you don't believe me.
-jon
RE: template encodings
Posted by Paulo Gaspar <pa...@krankikom.de>.
> > Is JOE NEWBIE supposed to, at least, know some Java?
> >
> > You got your idea trough, but most people posting on this thread
> > just do NOT agree with your idea that programmers are not supposed
> > to read the documentation.
>
> The above is a grotesque distortion of what I was saying.
I explain, this is the ironic part:
> Is JOE NEWBIE supposed to, at least, know some Java?
This is the point:
> You got your idea trough, but most people posting on this thread
> just do NOT agree with your idea that programmers are not supposed
> to read the documentation.
And it is very hard to understand you (repeated) statements about the
issue in any other way.
> Also, at this stage, it is fairly clear to me that it is the other
> people in the thread who just can't let go.
Can you?
My point is:
- we just do not agree and the majority does not have to follow a
single person's opinion.
Should we all let go?
OTOH, you can modify the code the way you see fit for your own use.
I just miss the usefulness of blaming "everybody else" (another irony)
and the list's culture.
Have fun,
Paulo
> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
>
> Paulo Gaspar wrote:
> >
> > Dear Jonathan,
> >
> > Is JOE NEWBIE supposed to, at least, know some Java?
> >
> > You got your idea trough, but most people posting on this thread
> > just do NOT agree with your idea that programmers are not supposed
> > to read the documentation.
>
> The above is a grotesque distortion of what I was saying.
>
> >
> > We also do not agree with the idea that a potentially dangerous
> > option should be ON by default.
> >
> > You see, it is nothing personal: we just do NOT agree with the
> > ideas you exposed.
> >
> > Now, I could not care less about your background or the weather
> > there. I just care if the ideas you expose make sense or not.
> >
> > BTW, these are a few things that do not help when you want to
> > put your ideas trough:
> > - Writing complete sentences in uppercase;
> > - Being impolite;
> > - Assuming too much about how another poster is or about what
> > he pretends;
> > - Not attacking someone that respected in the list for his
> > civility and very hard work.
> >
> > And in my (repeated) experience, Geir DOES try to understand
> > what anyone has to say even when initially it does not sound so
> > interesting to him and he often ends up implementing those
> > ideas.
> >
> > > In all likelihood, I will unsubscribe from this list shortly!
> >
> > Very personal opinion: be my guest, the value you added to this
> > list up to now does not seem to balance the damage.
>
>
> I have already admitted that I overreacted and got annoyed too easily.
> However, I do not believe that this has got so bad solely due to me. I
> am certain that, given the personalities and basic "culture" here, this
> kind of flare-up will be a frequent happening after I unsubscribe from
> the list. I suspect that stuff like this happened often before I ever
> subscribed.
>
> Also, at this stage, it is fairly clear to me that it is the other
> people in the thread who just can't let go.
>
> --
> 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/
>
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
Paulo Gaspar wrote:
>
> Dear Jonathan,
>
> Is JOE NEWBIE supposed to, at least, know some Java?
>
> You got your idea trough, but most people posting on this thread
> just do NOT agree with your idea that programmers are not supposed
> to read the documentation.
The above is a grotesque distortion of what I was saying.
>
> We also do not agree with the idea that a potentially dangerous
> option should be ON by default.
>
> You see, it is nothing personal: we just do NOT agree with the
> ideas you exposed.
>
> Now, I could not care less about your background or the weather
> there. I just care if the ideas you expose make sense or not.
>
> BTW, these are a few things that do not help when you want to
> put your ideas trough:
> - Writing complete sentences in uppercase;
> - Being impolite;
> - Assuming too much about how another poster is or about what
> he pretends;
> - Not attacking someone that respected in the list for his
> civility and very hard work.
>
> And in my (repeated) experience, Geir DOES try to understand
> what anyone has to say even when initially it does not sound so
> interesting to him and he often ends up implementing those
> ideas.
>
> > In all likelihood, I will unsubscribe from this list shortly!
>
> Very personal opinion: be my guest, the value you added to this
> list up to now does not seem to balance the damage.
I have already admitted that I overreacted and got annoyed too easily.
However, I do not believe that this has got so bad solely due to me. I
am certain that, given the personalities and basic "culture" here, this
kind of flare-up will be a frequent happening after I unsubscribe from
the list. I suspect that stuff like this happened often before I ever
subscribed.
Also, at this stage, it is fairly clear to me that it is the other
people in the thread who just can't let go.
--
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/
RE: template encodings
Posted by Paulo Gaspar <pa...@krankikom.de>.
Dear Jonathan,
Is JOE NEWBIE supposed to, at least, know some Java?
You got your idea trough, but most people posting on this thread
just do NOT agree with your idea that programmers are not supposed
to read the documentation.
We also do not agree with the idea that a potentially dangerous
option should be ON by default.
You see, it is nothing personal: we just do NOT agree with the
ideas you exposed.
Now, I could not care less about your background or the weather
there. I just care if the ideas you expose make sense or not.
BTW, these are a few things that do not help when you want to
put your ideas trough:
- Writing complete sentences in uppercase;
- Being impolite;
- Assuming too much about how another poster is or about what
he pretends;
- Not attacking someone that respected in the list for his
civility and very hard work.
And in my (repeated) experience, Geir DOES try to understand
what anyone has to say even when initially it does not sound so
interesting to him and he often ends up implementing those
ideas.
> In all likelihood, I will unsubscribe from this list shortly!
Very personal opinion: be my guest, the value you added to this
list up to now does not seem to balance the damage.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
>
> "Geir Magnusson Jr." wrote:
>
> I AM SICK AND TIRED OF THIS! ALL I AM SAYING IS SOMETHING REALLY REALLY
> SIMPLE!!!!
>
> JOE NEWBIE WILL ALMOST INEVITABLY AT SOME POINT WHEN MUCKING WITH
> VELOCITY FOR THE FIRST TIME, WRITE CODE LIKE THIS:
>
> mytemplate = Velocity.getTemplate("C:\\mypath\\myLittleTemplate");
>
> JOE NEWBIE WILL BE CONFUSED WHEN THIS DOESN'T WORK!
>
> IT WOULD BE BETTER IF THIS DID WORK IN THE DEFAULT OUT-OF-THE-BOX
> CONFIGURATION!
>
> The security issues don't matter if somebody is just trying to get
> Hello, World to work.
> IMHO, the out-of-the-box configuration should be extremely oriented
> towards getting things to work for Joe Newbie.
>
>
> >
> > Jonathan Revusky wrote:
> > >
> > > "Geir Magnusson Jr." wrote:
> > > >
> > > > Jonathan Revusky wrote:
> > > > >
> > > > >
> > > > > I don't care that much really. I do agree that the use of
> absolute paths
> > > > > should be discouraged. I'm not sure that I can take the
> security hole
> > > > > argument that seriously, because I think it's pretty
> tenuous. As long as
> > > > > you don't put the raw templates somewhere that's visible
> to the outside
> > > > > world, I don't for the life of me see the issue. It's
> just that the
> > > > > approved pattern is surely to specify resources relative
> to the insides
> > > > > of a .war file. So these things should be loaded relative to the
> > > > > classloader classpath.
> > > >
> > > > I was really trying to stay out of this hoping you would run out of
> > > > steam on this, but I can't resist here.
> > > >
> > > > The core Velocity resource loaders have *no* notion of the
> concept of
> > > > running in a servlet engine, let alone a WAR file.
> Velocity is general
> > > > purpose, not made for the web. Therefore, the
> configuration assuptions
> > > > MUST be general. This is why I say that while '.' isn't
> perfect, "/"
> > > > isn't either, because somone somewhere will not like the
> choice made.
> > >
> > > Well, you do seem argumentative, Geir. You certainly *can*
> make loading
> > > from the classpath the default behavior whether you have a servlet or
> > > not. (Meanwhile, in practice, 99% of your user base is using Velocity
> > > for servlets probably...) But for better or for worse,
> stand-alone java
> > > apps also have a classpath. I mean, it's like there's this
> argumentative
> > > compulsion to imply that I'm just not getting it somehow...
> >
> > I admit I had lustful zeal for argument in my younger days, mostly on
> > alt.fan.bill-gates, but no more.
>
> Gee, now, I'm curious, when you mention your younger days. Well,
> personally, I'm 36. I mean, how old are you? I'm guessing
> mid-twenties... I don't get a sense of great perspective and maturity...
> I sense good will, that you're not a bad guy and all, but I sense a
> large amount of immaturity...
>
> >
> > At this point, you are starting to change what I am apparently being
> > argumentative about.
> >
> > You are right. You *can* make loading from the classpath the default
> > behavior, however files are the most common way people do it 'out of the
> > box' and don't want/need to diddle with the classpath.
> >
> > Read what you wrote above. You blew off David's argument by making a
> > statement entirely in conflict with your fundamental assertion driving
> > this thread. I follwed up nothing that Velocity isn't web specific -
> > and I should have added that there is no 'approved pattern' in general.
> > Yes, there is an approved pattern for the web, and yes that's the
> > majority of users, but it is still general purpose.
> >
> > Your fundamental assertion, as I understand it, is that any template
> > request specified from the root of the filesystem should be honored by
> > default.
>
> My fundamental assertion is restated all in caps at the very top of this
> message.
>
> <SIGH>
>
> >
> > However, you then said
> >
> > "As long as you don't put the raw templates somewhere that's visible to
> > the outside world, I don't for the life of me see the issue."
> >
> > If any file on the file system is accessable, then raw templates,
> > password files, mail lists, credit card numbers, database files, are all
> > possibly visible to the outside world.
>
> Only if somebody writes explicitly in the code:
>
> Velocity.getTemplate("/the/path/to/theFileWithCreditCardInfo");
>
> AND if the file is readable by your servlet server process, which means
> that somebody did a brain fart!
>
> In any case, I am not talking about deployment on a server with
> sensitive info. One should be careful about what the various policies
> are when you finally deploy in a production environment.
>
> I am talking about JOE NEWBIE GETTING HELLO, WORLD WORKING!!!
>
> >
> > You then followed it with
> >
> > "It's just that the approved pattern is surely to specify resources
> > relative to the insides of a .war file."
> >
> > in which case your fundamental assertion is again in conflict, because
> > thats not the root of the filesystem either.
> >
> > Further, to load from the root of war, you either need to configure the
> > FileResourceLoader correctly (which servlet_example2) does, or use a
> > loader like the ClasspathResourceLoader within which the 'root of the
> > filesystem' is a meaningless concept.
> >
> > > (You don't know me, I know, but I really am a very strong java
> > > developer, you know... I do understand this stuff! :-))
> >
> > I have never once publicly questioned your competence. That isn't
> > really germaine to the discussion.
>
> Look, I have said that you're not a bad guy, and I have said that I
> overreacted yesterday. I'm sorry about that. But OTOH, I probably will
> never ever try to *tell* you anything in the future. I will probably
> never make a comment of any sort about any of your work ever again. It's
> too much bother! In all likelihood, I will unsubscribe from this list
> shortly!
>
> >
> > 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!
>
>
> 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/
>
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
I AM SICK AND TIRED OF THIS! ALL I AM SAYING IS SOMETHING REALLY REALLY
SIMPLE!!!!
JOE NEWBIE WILL ALMOST INEVITABLY AT SOME POINT WHEN MUCKING WITH
VELOCITY FOR THE FIRST TIME, WRITE CODE LIKE THIS:
mytemplate = Velocity.getTemplate("C:\\mypath\\myLittleTemplate");
JOE NEWBIE WILL BE CONFUSED WHEN THIS DOESN'T WORK!
IT WOULD BE BETTER IF THIS DID WORK IN THE DEFAULT OUT-OF-THE-BOX
CONFIGURATION!
The security issues don't matter if somebody is just trying to get
Hello, World to work.
IMHO, the out-of-the-box configuration should be extremely oriented
towards getting things to work for Joe Newbie.
>
> Jonathan Revusky wrote:
> >
> > "Geir Magnusson Jr." wrote:
> > >
> > > Jonathan Revusky wrote:
> > > >
> > > >
> > > > I don't care that much really. I do agree that the use of absolute paths
> > > > should be discouraged. I'm not sure that I can take the security hole
> > > > argument that seriously, because I think it's pretty tenuous. As long as
> > > > you don't put the raw templates somewhere that's visible to the outside
> > > > world, I don't for the life of me see the issue. It's just that the
> > > > approved pattern is surely to specify resources relative to the insides
> > > > of a .war file. So these things should be loaded relative to the
> > > > classloader classpath.
> > >
> > > I was really trying to stay out of this hoping you would run out of
> > > steam on this, but I can't resist here.
> > >
> > > The core Velocity resource loaders have *no* notion of the concept of
> > > running in a servlet engine, let alone a WAR file. Velocity is general
> > > purpose, not made for the web. Therefore, the configuration assuptions
> > > MUST be general. This is why I say that while '.' isn't perfect, "/"
> > > isn't either, because somone somewhere will not like the choice made.
> >
> > Well, you do seem argumentative, Geir. You certainly *can* make loading
> > from the classpath the default behavior whether you have a servlet or
> > not. (Meanwhile, in practice, 99% of your user base is using Velocity
> > for servlets probably...) But for better or for worse, stand-alone java
> > apps also have a classpath. I mean, it's like there's this argumentative
> > compulsion to imply that I'm just not getting it somehow...
>
> I admit I had lustful zeal for argument in my younger days, mostly on
> alt.fan.bill-gates, but no more.
Gee, now, I'm curious, when you mention your younger days. Well,
personally, I'm 36. I mean, how old are you? I'm guessing
mid-twenties... I don't get a sense of great perspective and maturity...
I sense good will, that you're not a bad guy and all, but I sense a
large amount of immaturity...
>
> At this point, you are starting to change what I am apparently being
> argumentative about.
>
> You are right. You *can* make loading from the classpath the default
> behavior, however files are the most common way people do it 'out of the
> box' and don't want/need to diddle with the classpath.
>
> Read what you wrote above. You blew off David's argument by making a
> statement entirely in conflict with your fundamental assertion driving
> this thread. I follwed up nothing that Velocity isn't web specific -
> and I should have added that there is no 'approved pattern' in general.
> Yes, there is an approved pattern for the web, and yes that's the
> majority of users, but it is still general purpose.
>
> Your fundamental assertion, as I understand it, is that any template
> request specified from the root of the filesystem should be honored by
> default.
My fundamental assertion is restated all in caps at the very top of this
message.
<SIGH>
>
> However, you then said
>
> "As long as you don't put the raw templates somewhere that's visible to
> the outside world, I don't for the life of me see the issue."
>
> If any file on the file system is accessable, then raw templates,
> password files, mail lists, credit card numbers, database files, are all
> possibly visible to the outside world.
Only if somebody writes explicitly in the code:
Velocity.getTemplate("/the/path/to/theFileWithCreditCardInfo");
AND if the file is readable by your servlet server process, which means
that somebody did a brain fart!
In any case, I am not talking about deployment on a server with
sensitive info. One should be careful about what the various policies
are when you finally deploy in a production environment.
I am talking about JOE NEWBIE GETTING HELLO, WORLD WORKING!!!
>
> You then followed it with
>
> "It's just that the approved pattern is surely to specify resources
> relative to the insides of a .war file."
>
> in which case your fundamental assertion is again in conflict, because
> thats not the root of the filesystem either.
>
> Further, to load from the root of war, you either need to configure the
> FileResourceLoader correctly (which servlet_example2) does, or use a
> loader like the ClasspathResourceLoader within which the 'root of the
> filesystem' is a meaningless concept.
>
> > (You don't know me, I know, but I really am a very strong java
> > developer, you know... I do understand this stuff! :-))
>
> I have never once publicly questioned your competence. That isn't
> really germaine to the discussion.
Look, I have said that you're not a bad guy, and I have said that I
overreacted yesterday. I'm sorry about that. But OTOH, I probably will
never ever try to *tell* you anything in the future. I will probably
never make a comment of any sort about any of your work ever again. It's
too much bother! In all likelihood, I will unsubscribe from this list
shortly!
>
> 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!
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jonathan Revusky wrote:
>
> "Geir Magnusson Jr." wrote:
> >
> > Jonathan Revusky wrote:
> > >
> > >
> > > I don't care that much really. I do agree that the use of absolute paths
> > > should be discouraged. I'm not sure that I can take the security hole
> > > argument that seriously, because I think it's pretty tenuous. As long as
> > > you don't put the raw templates somewhere that's visible to the outside
> > > world, I don't for the life of me see the issue. It's just that the
> > > approved pattern is surely to specify resources relative to the insides
> > > of a .war file. So these things should be loaded relative to the
> > > classloader classpath.
> >
> > I was really trying to stay out of this hoping you would run out of
> > steam on this, but I can't resist here.
> >
> > The core Velocity resource loaders have *no* notion of the concept of
> > running in a servlet engine, let alone a WAR file. Velocity is general
> > purpose, not made for the web. Therefore, the configuration assuptions
> > MUST be general. This is why I say that while '.' isn't perfect, "/"
> > isn't either, because somone somewhere will not like the choice made.
>
> Well, you do seem argumentative, Geir. You certainly *can* make loading
> from the classpath the default behavior whether you have a servlet or
> not. (Meanwhile, in practice, 99% of your user base is using Velocity
> for servlets probably...) But for better or for worse, stand-alone java
> apps also have a classpath. I mean, it's like there's this argumentative
> compulsion to imply that I'm just not getting it somehow...
I admit I had lustful zeal for argument in my younger days, mostly on
alt.fan.bill-gates, but no more.
At this point, you are starting to change what I am apparently being
argumentative about.
You are right. You *can* make loading from the classpath the default
behavior, however files are the most common way people do it 'out of the
box' and don't want/need to diddle with the classpath.
Read what you wrote above. You blew off David's argument by making a
statement entirely in conflict with your fundamental assertion driving
this thread. I follwed up nothing that Velocity isn't web specific -
and I should have added that there is no 'approved pattern' in general.
Yes, there is an approved pattern for the web, and yes that's the
majority of users, but it is still general purpose.
Your fundamental assertion, as I understand it, is that any template
request specified from the root of the filesystem should be honored by
default.
However, you then said
"As long as you don't put the raw templates somewhere that's visible to
the outside world, I don't for the life of me see the issue."
If any file on the file system is accessable, then raw templates,
password files, mail lists, credit card numbers, database files, are all
possibly visible to the outside world.
You then followed it with
"It's just that the approved pattern is surely to specify resources
relative to the insides of a .war file."
in which case your fundamental assertion is again in conflict, because
thats not the root of the filesystem either.
Further, to load from the root of war, you either need to configure the
FileResourceLoader correctly (which servlet_example2) does, or use a
loader like the ClasspathResourceLoader within which the 'root of the
filesystem' is a meaningless concept.
> (You don't know me, I know, but I really am a very strong java
> developer, you know... I do understand this stuff! :-))
I have never once publicly questioned your competence. That isn't
really germaine to the discussion.
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
>
> Jonathan Revusky wrote:
> >
> > David Kinnvall wrote:
> > >
> > > From: "Jonathan Revusky" <jr...@terra.es>
> > > > David Kinnvall wrote:
> > > > > /etc/passwd is absolute and exists. Or am I missing something?
> > > >
> > > > Yes, I think you are definitely missing something. That's why there are
> > > > security mechanisms in the OS and in the JVM. Modern computing is built
> > > > on many levels and it is not really the role of template engine code to
> > > > set security policies. Developers of code at that level of the equation
> > > > should concentrate on making their product usable.
> > >
> > > It was an example. I agree with the rest you say, however.
> > >
> > > > Similarly, if I gave an XML parser an absolute path to a file to parse,
> > > > it should not refuse to parse it in my better interests etcetera. I
> > > > would consider that equally inappropriate.
> > >
> > > Indeed. To allow using templates with absolute paths in
> > > any directory you wish _is_ a configuration option, though.
> >
> > Yes, I have been told that and I know that.
> >
> > >
> > > > The use of '.' as a default is clearly broken, since it will basically
> > > > never do anything useful. IMO, the default should probably be reading
> > > > relative to the classloader and then system classpaths. I also think
> > > > that if somebody says getTemplate("/full/path/to/file") it should fish
> > > > out the template. At least in the default, out-of-the-box configuration,
> > > > because you will definitely create scenarios where people bang their
> > > > heads against the wall not understanding what is wrong.
> > >
> > > You are of course entitled to your opinion. To make what
> > > you suggest the default in Velocity should be discussed
> > > a bit more however, to find out whether it is indeed the
> > > wish of the majority.
> >
> > I don't care that much really. I do agree that the use of absolute paths
> > should be discouraged. I'm not sure that I can take the security hole
> > argument that seriously, because I think it's pretty tenuous. As long as
> > you don't put the raw templates somewhere that's visible to the outside
> > world, I don't for the life of me see the issue. It's just that the
> > approved pattern is surely to specify resources relative to the insides
> > of a .war file. So these things should be loaded relative to the
> > classloader classpath.
>
> I was really trying to stay out of this hoping you would run out of
> steam on this, but I can't resist here.
>
> The core Velocity resource loaders have *no* notion of the concept of
> running in a servlet engine, let alone a WAR file. Velocity is general
> purpose, not made for the web. Therefore, the configuration assuptions
> MUST be general. This is why I say that while '.' isn't perfect, "/"
> isn't either, because somone somewhere will not like the choice made.
Well, you do seem argumentative, Geir. You certainly *can* make loading
from the classpath the default behavior whether you have a servlet or
not. (Meanwhile, in practice, 99% of your user base is using Velocity
for servlets probably...) But for better or for worse, stand-alone java
apps also have a classpath. I mean, it's like there's this argumentative
compulsion to imply that I'm just not getting it somehow...
(You don't know me, I know, but I really am a very strong java
developer, you know... I do understand this stuff! :-))
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jonathan Revusky wrote:
>
> David Kinnvall wrote:
> >
> > From: "Jonathan Revusky" <jr...@terra.es>
> > > David Kinnvall wrote:
> > > > /etc/passwd is absolute and exists. Or am I missing something?
> > >
> > > Yes, I think you are definitely missing something. That's why there are
> > > security mechanisms in the OS and in the JVM. Modern computing is built
> > > on many levels and it is not really the role of template engine code to
> > > set security policies. Developers of code at that level of the equation
> > > should concentrate on making their product usable.
> >
> > It was an example. I agree with the rest you say, however.
> >
> > > Similarly, if I gave an XML parser an absolute path to a file to parse,
> > > it should not refuse to parse it in my better interests etcetera. I
> > > would consider that equally inappropriate.
> >
> > Indeed. To allow using templates with absolute paths in
> > any directory you wish _is_ a configuration option, though.
>
> Yes, I have been told that and I know that.
>
> >
> > > The use of '.' as a default is clearly broken, since it will basically
> > > never do anything useful. IMO, the default should probably be reading
> > > relative to the classloader and then system classpaths. I also think
> > > that if somebody says getTemplate("/full/path/to/file") it should fish
> > > out the template. At least in the default, out-of-the-box configuration,
> > > because you will definitely create scenarios where people bang their
> > > heads against the wall not understanding what is wrong.
> >
> > You are of course entitled to your opinion. To make what
> > you suggest the default in Velocity should be discussed
> > a bit more however, to find out whether it is indeed the
> > wish of the majority.
>
> I don't care that much really. I do agree that the use of absolute paths
> should be discouraged. I'm not sure that I can take the security hole
> argument that seriously, because I think it's pretty tenuous. As long as
> you don't put the raw templates somewhere that's visible to the outside
> world, I don't for the life of me see the issue. It's just that the
> approved pattern is surely to specify resources relative to the insides
> of a .war file. So these things should be loaded relative to the
> classloader classpath.
I was really trying to stay out of this hoping you would run out of
steam on this, but I can't resist here.
The core Velocity resource loaders have *no* notion of the concept of
running in a servlet engine, let alone a WAR file. Velocity is general
purpose, not made for the web. Therefore, the configuration assuptions
MUST be general. This is why I say that while '.' isn't perfect, "/"
isn't either, because somone somewhere will not like the choice made.
That said, we provide a convenience base class 'VelcityServlet' which
offers a *suggestion* of how to use Velocity in a servlet environment,
but no demands - you don't have to use it.
Further, you can use servlet_example2, which does establish the root of
the webapp as the template path automaticall in a container that
supports it, so as a newbie user, you don't have to do anything to set
it up and just ask for templates relative to 'root', in this case the
root of the webapp. And you don't even have to read the documentation.
>
> OTOH, the classloader classpath is *not* the default. The *default* is
> to load relative to '.' the current working directory and that really is
> useless AFAICS.
>
> Now, I still would argue that if somebody actually does specify an
> absolute file location in a call to getTemplate() that it should work in
> the out-of-the-box configuration. But hey, it's not *my* library, so all
> I can do is give my opinion on that and my reasoning.
>
> >
> > > Your example is silly, contrived really, because a naive template coder
> > > is not going to code #include "/etc/passwd" in a template anyway. Those
> > > people develop on Windows or Mac and don't even know that /etc/passwd
> > > exists.
> >
> > It was an example, contrived or not, of the fact that
> > there may very well be files accessible, with no OS
> > protection, that I do not wish template developers to
> > have access to, intentionally or not. If you are so
> > obviously determined to understand otherwise, I give
> > up this part of the discussion. It serves no purpose.
>
> Well, then the same argument applies to what you're telling me above. If
> the default were that absolute pathnames worked, you could change the
> configuration!
>
> I'm not talking about a deployment situation anyway. I'm talking about a
> situation where a newbie downloads the ruddy thing and tries to get a
> simple example going on his local box. IMO, this scenario should be made
> as easy as is possible! Like, c'mon, what security issue is there when
> you're trying to get Hello, World to run?
Yes - and there is an example that does it 'out of the box' including
simple README on how to do it. No cofiguration needed. If that is too
damn difficult, I will make a WAR and include that. If that doesn't
work, maybe well offer onsite setup and demonstrations...
>
> >
> > > > Serious developers definitely read the documentation.
> > > > To suggest otherwise makes your case substantially weaker.
> > >
> > > This is utter bullshit. "Serious" developers do not *definitely* read
> > > the documentation. You (and Geir) will be well served to realize this.
> >
> > Right...
> >
> > > Serious developers typically start with the "Hello, World" example and
> > > start hacking around and trying to figure out how to do what they need
> > > to do from there.
> >
> > You have a different definition of serious developer than I do.
> > That is ok, but don't try to enforce your definition upon the
> > rest of the world, please.
>
> I don't know how many people would meet your definition of "serious
> developer".
>
> >
> > > If you claimed to me that you always fully read the documentation when
> > > trying to use something, I wouldn't even believe you. I would suspect
> > > insincerity.
> >
> > Did I claim that? No. I do claim, however, that I _do_
> > read enough docs to know what I am supposed to do to get
> > started, and to get a feel for what the developers intends
> > with their creation. How silly of me.
>
> No, I guess you didn't claim that about yourself. You made some claim
> about "serious developers" and I inferred that you were self-classifying
> as one. You did not even explicitly say that you were a "serious
> developer".
>
> I'm not that concerned with whether I myself am a "serious developer". I
> have some good work habits and some not so good ones. I usually get the
> job done. I do not have infinite patience when it comes to rooting
> around in docs though. I would venture to say that most people don't.
>
> >
> > > Look, I don't want to argue with you. You suffer from the same disease
> > > and, judging by what you're saying, you're a far worse gone case.
> >
> > Why, thank you. How nice of you. And constructive.
>
> You seem to be trying to be more reasonable now. I am trying too, so
> I'll retract that.
>
> >
> > > I did overreact to Geir. I was not in a good mood. I had a good night's
> > > sleep and feel more conciliatory. Look, overall, Geir is basically a
> > > good guy and he's right to keep trying to improve the documentation. But
> > > to think that everybody always reads the docs thorougly is outright
> > > silly. I don't think such nonsense should be encouraged.
> >
> > You did indeed overreact.
> >
> > Not in a good mood? You mean you are in a better
> > mood now? I would say that your accusation of me
> > suffering from some disease and being a "worse
> > gone case" is not a sign of being in a good mood.
> >
> > Geir is indeed a nice guy, as far as I have seen.
>
> Yeah, actually he seems okay. He is enthusiastic about Velocity and is
> putting a lot of work into it and that's good. Actually, he probably is
> more receptive to input than is readily obvious. He seems to spend huge
> energy justifying -- in cases, where somebody is not even making a
> criticism. I *never* said that the template encodings didn't work, yet
> he has repeatedly responded, as if I had indeed said that! I find it
> befuddling.
I kept responding because you didn't clearly get what I was saying, and
it appeared to me that you were confusing with the procedural
commonality of content created in the same encoding as the user base
with the technical procedure that Velocity goes through to handle
encodings. What I was trying to say is that the input decoding process
is completely decoupled from the output encoding, something which
velocity doesn't need to worry about by design, as it takes a generic
Writer for rendering.
> >
> > I did not, nor did anyone else, suggest thet everybody
> > should, or does, read the docs _thoroughly_. I did however
> > suggest that I, and those I defined as serious developers,
> > read the docs to find out how things are supposed to be
> > setup for proper usage. Is that too much to ask?
>
> The general gamut of human behavior is what it is and neither you nor I
> are going to change it. I think that insisting that something is in the
> docs, therefore there's no issue, is naive. The fact that a command in a
> makefile must start with a literal tab character and not 4 or 8 spaces
> is in the docs somewhere, but I consider that to be pretty broken also.
That's why we use ant.
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
David Kinnvall wrote:
>
> From: "Jonathan Revusky" <jr...@terra.es>
> > David Kinnvall wrote:
> > > /etc/passwd is absolute and exists. Or am I missing something?
> >
> > Yes, I think you are definitely missing something. That's why there are
> > security mechanisms in the OS and in the JVM. Modern computing is built
> > on many levels and it is not really the role of template engine code to
> > set security policies. Developers of code at that level of the equation
> > should concentrate on making their product usable.
>
> It was an example. I agree with the rest you say, however.
>
> > Similarly, if I gave an XML parser an absolute path to a file to parse,
> > it should not refuse to parse it in my better interests etcetera. I
> > would consider that equally inappropriate.
>
> Indeed. To allow using templates with absolute paths in
> any directory you wish _is_ a configuration option, though.
Yes, I have been told that and I know that.
>
> > The use of '.' as a default is clearly broken, since it will basically
> > never do anything useful. IMO, the default should probably be reading
> > relative to the classloader and then system classpaths. I also think
> > that if somebody says getTemplate("/full/path/to/file") it should fish
> > out the template. At least in the default, out-of-the-box configuration,
> > because you will definitely create scenarios where people bang their
> > heads against the wall not understanding what is wrong.
>
> You are of course entitled to your opinion. To make what
> you suggest the default in Velocity should be discussed
> a bit more however, to find out whether it is indeed the
> wish of the majority.
I don't care that much really. I do agree that the use of absolute paths
should be discouraged. I'm not sure that I can take the security hole
argument that seriously, because I think it's pretty tenuous. As long as
you don't put the raw templates somewhere that's visible to the outside
world, I don't for the life of me see the issue. It's just that the
approved pattern is surely to specify resources relative to the insides
of a .war file. So these things should be loaded relative to the
classloader classpath.
OTOH, the classloader classpath is *not* the default. The *default* is
to load relative to '.' the current working directory and that really is
useless AFAICS.
Now, I still would argue that if somebody actually does specify an
absolute file location in a call to getTemplate() that it should work in
the out-of-the-box configuration. But hey, it's not *my* library, so all
I can do is give my opinion on that and my reasoning.
>
> > Your example is silly, contrived really, because a naive template coder
> > is not going to code #include "/etc/passwd" in a template anyway. Those
> > people develop on Windows or Mac and don't even know that /etc/passwd
> > exists.
>
> It was an example, contrived or not, of the fact that
> there may very well be files accessible, with no OS
> protection, that I do not wish template developers to
> have access to, intentionally or not. If you are so
> obviously determined to understand otherwise, I give
> up this part of the discussion. It serves no purpose.
Well, then the same argument applies to what you're telling me above. If
the default were that absolute pathnames worked, you could change the
configuration!
I'm not talking about a deployment situation anyway. I'm talking about a
situation where a newbie downloads the ruddy thing and tries to get a
simple example going on his local box. IMO, this scenario should be made
as easy as is possible! Like, c'mon, what security issue is there when
you're trying to get Hello, World to run?
>
> > > Serious developers definitely read the documentation.
> > > To suggest otherwise makes your case substantially weaker.
> >
> > This is utter bullshit. "Serious" developers do not *definitely* read
> > the documentation. You (and Geir) will be well served to realize this.
>
> Right...
>
> > Serious developers typically start with the "Hello, World" example and
> > start hacking around and trying to figure out how to do what they need
> > to do from there.
>
> You have a different definition of serious developer than I do.
> That is ok, but don't try to enforce your definition upon the
> rest of the world, please.
I don't know how many people would meet your definition of "serious
developer".
>
> > If you claimed to me that you always fully read the documentation when
> > trying to use something, I wouldn't even believe you. I would suspect
> > insincerity.
>
> Did I claim that? No. I do claim, however, that I _do_
> read enough docs to know what I am supposed to do to get
> started, and to get a feel for what the developers intends
> with their creation. How silly of me.
No, I guess you didn't claim that about yourself. You made some claim
about "serious developers" and I inferred that you were self-classifying
as one. You did not even explicitly say that you were a "serious
developer".
I'm not that concerned with whether I myself am a "serious developer". I
have some good work habits and some not so good ones. I usually get the
job done. I do not have infinite patience when it comes to rooting
around in docs though. I would venture to say that most people don't.
>
> > Look, I don't want to argue with you. You suffer from the same disease
> > and, judging by what you're saying, you're a far worse gone case.
>
> Why, thank you. How nice of you. And constructive.
You seem to be trying to be more reasonable now. I am trying too, so
I'll retract that.
>
> > I did overreact to Geir. I was not in a good mood. I had a good night's
> > sleep and feel more conciliatory. Look, overall, Geir is basically a
> > good guy and he's right to keep trying to improve the documentation. But
> > to think that everybody always reads the docs thorougly is outright
> > silly. I don't think such nonsense should be encouraged.
>
> You did indeed overreact.
>
> Not in a good mood? You mean you are in a better
> mood now? I would say that your accusation of me
> suffering from some disease and being a "worse
> gone case" is not a sign of being in a good mood.
>
> Geir is indeed a nice guy, as far as I have seen.
Yeah, actually he seems okay. He is enthusiastic about Velocity and is
putting a lot of work into it and that's good. Actually, he probably is
more receptive to input than is readily obvious. He seems to spend huge
energy justifying -- in cases, where somebody is not even making a
criticism. I *never* said that the template encodings didn't work, yet
he has repeatedly responded, as if I had indeed said that! I find it
befuddling.
>
> I did not, nor did anyone else, suggest thet everybody
> should, or does, read the docs _thoroughly_. I did however
> suggest that I, and those I defined as serious developers,
> read the docs to find out how things are supposed to be
> setup for proper usage. Is that too much to ask?
The general gamut of human behavior is what it is and neither you nor I
are going to change it. I think that insisting that something is in the
docs, therefore there's no issue, is naive. The fact that a command in a
makefile must start with a literal tab character and not 4 or 8 spaces
is in the docs somewhere, but I consider that to be pretty broken also.
>
> Regards,
>
> David Kinnvall
--
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/
Re: template encodings
Posted by David Kinnvall <da...@alertir.com>.
From: "Jonathan Revusky" <jr...@terra.es>
> David Kinnvall wrote:
> > /etc/passwd is absolute and exists. Or am I missing something?
>
> Yes, I think you are definitely missing something. That's why there are
> security mechanisms in the OS and in the JVM. Modern computing is built
> on many levels and it is not really the role of template engine code to
> set security policies. Developers of code at that level of the equation
> should concentrate on making their product usable.
It was an example. I agree with the rest you say, however.
> Similarly, if I gave an XML parser an absolute path to a file to parse,
> it should not refuse to parse it in my better interests etcetera. I
> would consider that equally inappropriate.
Indeed. To allow using templates with absolute paths in
any directory you wish _is_ a configuration option, though.
> The use of '.' as a default is clearly broken, since it will basically
> never do anything useful. IMO, the default should probably be reading
> relative to the classloader and then system classpaths. I also think
> that if somebody says getTemplate("/full/path/to/file") it should fish
> out the template. At least in the default, out-of-the-box configuration,
> because you will definitely create scenarios where people bang their
> heads against the wall not understanding what is wrong.
You are of course entitled to your opinion. To make what
you suggest the default in Velocity should be discussed
a bit more however, to find out whether it is indeed the
wish of the majority.
> Your example is silly, contrived really, because a naive template coder
> is not going to code #include "/etc/passwd" in a template anyway. Those
> people develop on Windows or Mac and don't even know that /etc/passwd
> exists.
It was an example, contrived or not, of the fact that
there may very well be files accessible, with no OS
protection, that I do not wish template developers to
have access to, intentionally or not. If you are so
obviously determined to understand otherwise, I give
up this part of the discussion. It serves no purpose.
> > Serious developers definitely read the documentation.
> > To suggest otherwise makes your case substantially weaker.
>
> This is utter bullshit. "Serious" developers do not *definitely* read
> the documentation. You (and Geir) will be well served to realize this.
Right...
> Serious developers typically start with the "Hello, World" example and
> start hacking around and trying to figure out how to do what they need
> to do from there.
You have a different definition of serious developer than I do.
That is ok, but don't try to enforce your definition upon the
rest of the world, please.
> If you claimed to me that you always fully read the documentation when
> trying to use something, I wouldn't even believe you. I would suspect
> insincerity.
Did I claim that? No. I do claim, however, that I _do_
read enough docs to know what I am supposed to do to get
started, and to get a feel for what the developers intends
with their creation. How silly of me.
> Look, I don't want to argue with you. You suffer from the same disease
> and, judging by what you're saying, you're a far worse gone case.
Why, thank you. How nice of you. And constructive.
> I did overreact to Geir. I was not in a good mood. I had a good night's
> sleep and feel more conciliatory. Look, overall, Geir is basically a
> good guy and he's right to keep trying to improve the documentation. But
> to think that everybody always reads the docs thorougly is outright
> silly. I don't think such nonsense should be encouraged.
You did indeed overreact.
Not in a good mood? You mean you are in a better
mood now? I would say that your accusation of me
suffering from some disease and being a "worse
gone case" is not a sign of being in a good mood.
Geir is indeed a nice guy, as far as I have seen.
I did not, nor did anyone else, suggest thet everybody
should, or does, read the docs _thoroughly_. I did however
suggest that I, and those I defined as serious developers,
read the docs to find out how things are supposed to be
setup for proper usage. Is that too much to ask?
Regards,
David Kinnvall
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
David Kinnvall wrote:
>
> From: "Jonathan Revusky" <jr...@terra.es>
> > "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));
> > }
>
> /etc/passwd is absolute and exists. Or am I missing something?
Yes, I think you are definitely missing something. That's why there are
security mechanisms in the OS and in the JVM. Modern computing is built
on many levels and it is not really the role of template engine code to
set security policies. Developers of code at that level of the equation
should concentrate on making their product usable.
Similarly, if I gave an XML parser an absolute path to a file to parse,
it should not refuse to parse it in my better interests etcetera. I
would consider that equally inappropriate.
The use of '.' as a default is clearly broken, since it will basically
never do anything useful. IMO, the default should probably be reading
relative to the classloader and then system classpaths. I also think
that if somebody says getTemplate("/full/path/to/file") it should fish
out the template. At least in the default, out-of-the-box configuration,
because you will definitely create scenarios where people bang their
heads against the wall not understanding what is wrong.
Your example is silly, contrived really, because a naive template coder
is not going to code #include "/etc/passwd" in a template anyway. Those
people develop on Windows or Mac and don't even know that /etc/passwd
exists.
> I would certainly *not* want my system exposed via careless
> template coders in that way, unless explicitely authorized by
> me via configuration.
<snip>
>
> Serious developers definitely read the documentation.
> To suggest otherwise makes your case substantially weaker.
This is utter bullshit. "Serious" developers do not *definitely* read
the documentation. You (and Geir) will be well served to realize this.
Serious developers typically start with the "Hello, World" example and
start hacking around and trying to figure out how to do what they need
to do from there.
If you claimed to me that you always fully read the documentation when
trying to use something, I wouldn't even believe you. I would suspect
insincerity.
Look, I don't want to argue with you. You suffer from the same disease
and, judging by what you're saying, you're a far worse gone case.
I did overreact to Geir. I was not in a good mood. I had a good night's
sleep and feel more conciliatory. Look, overall, Geir is basically a
good guy and he's right to keep trying to improve the documentation. But
to think that everybody always reads the docs thorougly is outright
silly. I don't think such nonsense should be encouraged.
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/
Re: template encodings
Posted by David Kinnvall <da...@alertir.com>.
From: "Jonathan Revusky" <jr...@terra.es>
> "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));
> }
/etc/passwd is absolute and exists. Or am I missing something?
I would certainly *not* want my system exposed via careless
template coders in that way, unless explicitely authorized by
me via configuration.
> > > 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.
>From *your* point of view. Not mine.
> 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...
Serious developers definitely read the documentation.
To suggest otherwise makes your case substantially weaker.
> > > 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.
Geir is, from my experience with him and the list, definitely
*not* playing dumb. He is simply trying to get through to you.
He is failing. Utterly.
> > > 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.
It did not seem that way to me. You might try to read what he
actually says, rather than invent some convoluted underlying
meaning that better fits your urge to argue.
> > > 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.
You missed the point entirely, did you? Or are you actually
being serious? The one being arrogant here is not Geir, IMNSHO.
> > > 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.
True, but Geir is, again from my personal experience, not
playing innocent. He is trying to get through to you. And
still failing, apparently.
> > 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.
It seems a bit odd to me that you, after pointing at the
native Java support for this and that regarding files in
diverse file systems, should fail to see the validity in
Geir's reasoning about differing encodings in the input
and output and the Java platform's native support for this?
Are you deliberately trying to be argumentative?
On top of that, you are wrong. The application we are currently
building at my company stores all templates in UTF-8. Output,
however, varies wildly depending on users' settings and personal
preferences.
If it's confusing read the documentation. If the documentation
is confusing, suggest improvements. They *will* be included, if
they are valid. Trust me.
> > 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.)
You sir, are not only wasting Geir's time. You are also wasting
*my* time, and several others on this list without doubt. That
is unfortunate, since you showed great potential for constructive
reasoning in the beginning of the discussion.
> But do fix the thing about the absolute path instead of emitting all
> this hot air about proprietary file systems. Cripes!
Please calm down, and try to revert to your initial constructive
mode. That way we can try to actually improve matters.
Regards,
David Kinnvall
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"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?
>
> > 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....
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...)
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...
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...
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. 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.
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. 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.
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.
In short, Velocity is a pretty good product, but it certainly could be
better. 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.
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.)
So now, fellas, do be good...
:-)
> --
> 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!
--
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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.
> 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)
> 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.
geir
> 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/
--
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"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 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.
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.
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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.
Our regression testing suite even has a test, called EncodingTestCase,
that tests UTF-8, GBK (called 'high-byte' Chinese, I think) and KOI8-R,
which I believe is Cyrillic.
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"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.
Thanks,
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jonathan Revusky wrote:
>
> "Geir Magnusson Jr." wrote:
> >
> > 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.
>
> Nothing at all to do with it? I mean, as a purely theoretical matter,
> you're probably right. But if have a page encoded in ISO-8859-1, what is
> the likelihood that I will output this to a client using a different
> character encoding, like Arabic or Chinese? Surely, in practice, there
> is near-perfect correlation between the input encoding and the output
> encoding...
>
You aren't getting what I am saying :
The input encoding has nothing to do with the output encoding. The
input encoding is specified to convert a bytestream that is the
template into a set of characters that can be parsed. This is what
Velocity needs and cares about.
The output encoding is how your writer converts the rendered
characterstream into a bytestream for ouput. This configuration of the
writer is what you the application programmer do, and Velocity doesn't
care.
Velocity does have a configuration property OUTPUT_ENCODING, but this is
only used by the VelocityServlet convenience class and Anakia to have a
default encoding with which to configure the Writer.
With regards to 'in practice', that's only because people tend to work
in the encoding that is native to their locale or audience. But since
Velocity does decode every template from *some* encoding into
characters, it's irrelevant what you encode in.
> >
> > > >
> > > > 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.
>
> Yes, I do. I specify "Big5" for example in the case above, since that is
> the encoding for Taiwan. If a template file for the zh_TW locale is
> always encoded in Big5 then I'm A-OK.
That's right. As long as you either specify it at getTemplate() time,
or make it the default INPUT_ENCODING for Velocity.
> > Velocity
> > assumes that if you don't specify, the template byte stream (no matter
> > where it comes from) is encoded in ISO-8859-1
>
> Yeah, I noticed that, but I don't see why you use that rather than the
> platform's default encoding? You can get it via
> System.getProperty("file.encoding")
History, at this point. :) That can be changed.
> >
> > >
> > > 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. :)
>
> Yes, but that's the default encoding for anybody in the Western
> Hemisphere or Western Europe. So for the vast majority of your user
> base, the above distinction is quibbling.
Yep
>
> > 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
> > :)
>
> No, it wouldn't be just luck. I specify the encoding on the input side.
> The Niggle framework assumes that the encoding of a template named
> mytemplate_ru.html (You would fish that out as a result of looking for
> mytemplate.html from a context in the preferred locale was Russian,
> say.) And it assumes that the page template in question is encoded with
> the encoding used for that locale.
>
> Which is ISO-8859-5
>
> At least in the Freemarker/Webmacro bridge code, I was doing this. I had
> slipped up and was not doing so in the Velocity bridge code, but I only
> wrote that yesterday. :-)
Cool - Because you impliticly note the encoding in the template name, I
think that incorporating this aspect with Velocity will be very easy for
you.
> Now, I'm using the same scheme with velocity.
>
> >
> > > >
> > > > 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.
>
> 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?
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"Geir Magnusson Jr." wrote:
>
> 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.
Nothing at all to do with it? I mean, as a purely theoretical matter,
you're probably right. But if have a page encoded in ISO-8859-1, what is
the likelihood that I will output this to a client using a different
character encoding, like Arabic or Chinese? Surely, in practice, there
is near-perfect correlation between the input encoding and the output
encoding...
>
> > >
> > > 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.
Yes, I do. I specify "Big5" for example in the case above, since that is
the encoding for Taiwan. If a template file for the zh_TW locale is
always encoded in Big5 then I'm A-OK.
> Velocity
> assumes that if you don't specify, the template byte stream (no matter
> where it comes from) is encoded in ISO-8859-1
Yeah, I noticed that, but I don't see why you use that rather than the
platform's default encoding? You can get it via
System.getProperty("file.encoding")
>
> >
> > 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. :)
Yes, but that's the default encoding for anybody in the Western
Hemisphere or Western Europe. So for the vast majority of your user
base, the above distinction is quibbling.
> 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
> :)
No, it wouldn't be just luck. I specify the encoding on the input side.
The Niggle framework assumes that the encoding of a template named
mytemplate_ru.html (You would fish that out as a result of looking for
mytemplate.html from a context in the preferred locale was Russian,
say.) And it assumes that the page template in question is encoded with
the encoding used for that locale.
Which is ISO-8859-5
At least in the Freemarker/Webmacro bridge code, I was doing this. I had
slipped up and was not doing so in the Velocity bridge code, but I only
wrote that yesterday. :-)
Now, I'm using the same scheme with velocity.
>
> > >
> > > 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.
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.
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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!
Re: template encodings
Posted by Jonathan Revusky <jr...@terra.es>.
"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.
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.
>
> 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.
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.
> t.merge( context, writer);
This is the method I was using it turns out.
>
> 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.
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/
Re: template encodings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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.
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 );
t.merge( context, writer);
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.
>
> IOW, this should really be the realm of responsibility of the underlying
> servlet engine AFAICS. (Though, that said, I *think* that extra i18n
> hook was added as of the 2.2 servlet spec. I explicitly say that Niggle
> requires >2.2 servlet engine.)
Like I said, this encoding flag is to specify the encoding of the
template for input. For ouput, you are right - it's up to you. I will
make this clearer in the docs.
> This is basically the assumption I have gone on in the Niggle framework.
> Funny thing, judging from servlet logs, I get a lot of downloads from
> Japan and Taiwan. And they keep coming back when I announce a new
> version. But I get no feedback from these people as to whether this
> actually works!
>
> In other matters, there is one person who I know to be subscribed to
> this list who expressed interest in using Niggle in conjunction with
> Velocity. (At the time, only Freemarker and WebMacro were supported.)
> There is a preview that allows usage of Velocity as the template engine
> available here:
>
> http://revusky.com/dist/niggle1_0_3pre.zip
That's great.
> If you simply read the various references to webmacro and mentally
> substitute in velocity, you should be able to get it working with
> velocity. There are sample velocity templates for the mini-rolodex
> sample app. I will have to patch up the docs before I announce this.
> (Probably before mid-week.)
Very cool. Let us know.
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!