On 7/14/02 5:43 PM, "Stephen Haberman" <[EMAIL PROTECTED]> wrote:

>> 
>> I didn't look at the patch - but doesn't this mean you'll have to put
> the
>> properties file in path accessible to the resource loader?
>> 
> 
> Yes. I'm not aware of the best practices/current style of where to put
> properties files, but Torque has them mixed in with the templates. Well,
> and the test bed naturally has the properties files mixed in with the
> templates also.
> 
> Hm. Shoot. So I suppose you're saying it's not good to force a resource
> loader to be used in loading a properties file?

Not saying anything.  Just asking.  :)

If Torque / Texen practice is to mix the properties there, then this seems a
perfectly reasonable approach, as 'getContent()' while intended to return
content to be presented in the rendered output, is just text-ish stuff from
the resource path that won't be parsed.

>I thought it made things
> a lot cleaner, but I was under the assumption that properties files
> wouldn't be coming in from places not already available to the resource
> loader(s).

Again, that makes sense to me too if that's what people normally do with
Texen/Torque.
 
> Perhaps I'm missing some, but the only location properties could be that
> perhaps works in the current PropertiesUtil but not the patch is if
> they're referred to with a full path (e.g. c:\offinanotherdir) or
> relative paths that back out of the dir the file resource loader is
> pointed at (e.g. ..\..\..\clearbackhere).

And that stinks :)
 
> Yeah, and I just reviewed FileResourceLoader and it looks like your
> specifically trying to prevent that with the StringUtils.normalizePath
> stuff.
> 
> So, assuming this will break lots of Texen code (?), what if after
> trying Velocity's resource loader, if a ResourceNotFoundException occurs
> from the RuntimeSingleton.getContent, I just in some code that tries
> loading the properties file off the hard drive?
> 
> If the properties file was in the classpath, template path, or any other
> resource, it would have been found by Velocity, so it'd only have to try
> loading with the path as is and not worry about calculating any template
> path stuff.

That's not true - Velocity don't dig around anywhere other than where the
configured loaders look, and by default that's the file loader in the
current directory.

Just so you know where I'm coming from, my only concern is that this doesn't
break anyone, and second, it's not going to be a bear to maintain in the
future.  After that, if Texen users like it, I like it.

Another approach is to try to find the properties file in the classpath via
using the classloader, or letting it be set in some system property.  Is
that better/ more conventional/safer/ more elegant?


-- 
Geir Magnusson Jr. 
Research & Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to