On Wednesday, November 27, 2002, at 03:38 PM, Bill Burton wrote:
Found the vDoclet version. All it does is direct ERROR level messages to System.err. All other messages are dropped. So it's acting as a filter to only allow errors to be displayed. As it's logging to System.err, it's not integrating with Ant's logging API.I haven't looked at what vDoclet does for logging integration but if it's a better solution, maybe it could be used instead.Ah - right. This is why I'm resistant to putting things like this in the velocity core, as when you find something different/better, we have to support the old.
However, in the version used with DVSL, it matches up the Velocity logging levels with Ant's and then delegates to Ant's logger. The result is all Velocity logging messages are sent to Ant but are only output if Ant's current logging level is high enough. Really simple stuff. The only thing is someone might disagree with is the mapping between the Velocity log levels and Ant's as there is a little room for interpretation there.
Right - that's cool.
Right, but that's not too different than other things - it allows something like that to be rapidly rev-ed w/o having the whole velocity rapidly rev-ed. (Yes, I can just hear the chortles... I'm laughing too...)Instead, if they were in Velocity tools, with good docs, then it's a natural thing to have *that* be the place for extensions like this. Still supported, still documented, still good code - but not part of the core.But then for this one bit of functionality, someone has to add a whole new .jar which is released separately (but which hasn't been released yet :) ).
[SNIP]
Right now, Resource Loaders are statically defined. You just configure and use them. However, certain types of Resource Loaders are not possible to write without being able to pass state information contained in the current request (using web terminology) down to the loader. Such a capability would allow a Loader to dynamically return a different templace depending on what information was passed to it each time it was called.Hm. - how about in the template string?
getTemplate("mytemplate?a=b&c=d&e=f");
couldn't you write a loader that does that? What extra support does one need? [Honest question]
I didn't mean you, but this whole general thing. No worries. My problem.Right - but I think that we aren't adding new things here. I see 2.0 as a big step.I don't think a 2.0 is warranted unless the float change is significant enough. I guess if it is, then indeed a 2.0 is right.
I don't think it has anything to do with how significant the internal changes are but more that it has the perception of major new functionality. It's *much* easier to tell people they need 2.0 for these these features than to say that 1.4 is needed for one feature and then 1.5 adds some other new feature, etc. Also, with a major revision change, people will *expect* major new features.
Or, the culmination of many small ones? :)Sorry. Had no intention of upsetting you. Was just suggesting one possible way to hopefully solve several problems at once.Also, releasing 2.0 may mean the possibility of allowing slight issues with backwards compatibility (such as with floats and division). But of course, every effort should be made to maintain backwards compatibility with the 1.x versions.I'm going to make the time. This whole thread has upset me quite a bit (hence my snapping at Christoph - I'm sorry...) and caused me to look around a bit at things. Changes need to be made.
It's clear 1.3 is overdue. I'll release it ASAP and get the patches in.
Well, when you have the time. We all know you're busy these days.
--
Geir Magnusson Jr 203-355-2219(w)
Adeptra, Inc. 203-247-1713(m)
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
