Nathan Bubna wrote:
Eelco Hillenius said:
For a project that I am doing I need the ability to construct Templates from plain Strings.
...
there does seem to be interest in this sorta thing lately...
Attached you find what I came up with. It would be great if you guys could give it a place in the project (or probably better the tools subproject).
hmm. so far, the tools subproject has been heavily aimed at web-dev support and so called "view tools" (objects placed in the context to perform/simplify various tasks at that level). inclusion of such things as alternate resource loaders, "custom" directives and the like has not really been discussed (at least, not since i came on board). however, i've begun to think lately that this warrants some discussion. after all, things like a StringResourceLoader or a Define directive certainly are "velocity tools" in the general sense of the word.
personally, i'm a little wary of this. if these are things people *use* (not just want!), but don't fit and get into velocity's core, then it would be nice to have a place for them to be tested and developed. however, as the scope of the project widens, it becomes all that much harder for the committers (just me lately) to follow and maintain. for instance, in my work, i presently have no use for a StringResourceLoader, nor do i anticipate any.
so, my general inclination is not to commit these things for others unless i'm sure there is sufficient demand for them to ensure that there will be contributers to support them.
I've not looked into the submitted StringResourceLoader implementations, I can imagine of two approaches to locate a cached template: a) using a "key" - which would be performant and safe b) using the string hashcode, which would be very flexible and a bit less performant
Such a loader should be available in the contrib are (or at least somewhere in the whiteboard, or even in this list).
what impressions of and desires for the goals of the velocity-tools project do you (whoever reads this) have? do you think it ought include these sort of "tools"? should the project have set, specific goals? what should those be? or do you see it as a place to collect all sorts of velocity tools/extras/utils?
IMHO, I believe the velocity-tools should contain commonly used add-ons to velocity, that can be simply included in a specific deplyment site. The instructions for each tool (bes in the apidoc) should state the steps to get the tool up-and-running and how it is to be used.
and specifically, i suppose i should ask who out there will use and/or support a StringResourceLoader? and with that, do you prefer Eelco's implementation (when it gets posted :) or the one Moshe posted to the user list?
Currently I've no use for a SRL, but currently ve.render(...) is sufficient for us performance wise. BUT, the stated/requested uses in this list seem to me very sensible, thus justifying the contribution.
Maybe Eelco and Moshe should cross evaluate the postings and join their forces?
what about Andrew's #define directive? (also posted/dicussed on the user list) would/does anyone else use or support that?
+1, I can use that one. From the top of my mind it contains some strange feature of post evaluation � la #macro, which should be verified, requires an unit test and must be such that future Vel versions don't break it.
IMHO, #define and #local should be in the core distribution.
just curious, no promises right now. :-) these things are unlikely to get in until we get a velocity-tools release out.
Nathan Bubna [EMAIL PROTECTED]
Thanks Nathan, for your active participation with your contributions and responses to this list!
I will also remain responsive on this list on issues that are not directly a special theme of of you (Nathan, Attila, etc.) should handle... I once asked Geir if he would consider me as a comitter, but have not urged, since mostly I can use velocity out-of-the-box and do not have any special itches to scrath (apart from the whitespace issues! - also see the "What say ye?"-Thread in March 2003).
-- :) Christoph Reck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
