This time, it's about tools reading external resources. I'd like to:

1) have ImportSupport and ImportTool also be available in generic tools
for absolute URLs, only the view versions being able to import a
relative URL

2) have XmlTool inherit from ImportSupport, to homogenize its behavior
with ImportTool

3) have a new generic JsonTool, in the same spirit


   #set($elements = $"https://some.external.api/elements.json";))
   #foreach($element in $elements) ...

4) Put back XmlTool in the velocity-tools-generic module, using shading
for the dom4j dependency. This is motivated by the fact that although
dom4j-1.6.1.jar weights 446k, shading only needs 152k out of it. So it's
a little loss for users not using the XmlTool, and a little gain for
users using the XmlTool (see the exact figures in the appended annex).
Not mentioning the gain in simplicity, one less jar...

5) have view versions of XmlTool and JsonTool, with the extra feature of
being able to handle query POST parameters that are in text/json and
text/xml format.

While I understand you idea, I do think that introducing stuff like this a bad idea for several reasons:

1. Processing of structured, low-level data like XML, JSON, form data always belongs to a controller and not to the view layer. The view layer should always receive a minimal set of high-level structures to do its task. 2. You are turning a template engine into a scripting engine which Velocity is not. 3. By having opening the door for #read("http..") people will start to ask for: How do I set credentials, how do I add request headers, how do I add my company's proxy, etc? At the end, you will find yourself implementing stuff people have already done several times.
4. and likely more.

The very same idea has been implemented on a lower level by the Plexus Resouce Loader [1] which in turn is used in LICENSE.vm in Maven [2] and guess what, every time someone tries to build Maven inside a company with a proxy, he/she waste some time to figure out why the build is hanging. One simple reason: the implementation so simple that you can't provide a proxy host to reach external hosts. What a pain!

In that spirit, keep the tools as simple as possible and as offline as possible. I would even go with the XML support available in Java. the DOM4J support was added in times where Java's native XML support was lousy.


[1] [2]

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to