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
Example:
#set($elements = $json.read("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.
Michael
[1]
https://codehaus-plexus.github.io/plexus-resources/apidocs/org/codehaus/plexus/resource/loader/URLResourceLoader.html
[2]
https://github.com/apache/maven/blob/master/apache-maven/src/main/appended-resources/META-INF/LICENSE.vm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
