I agree with Michael here, this direction is against what "pure"
Velocity is about. The generic tools shouldn't be allowed to fetch
random resources off the internet.
I'm also against propagating the dependency on DOM4J, a library which
has been dead for ten years.
I'm OK with adding tools for working with JSON and XML, as long as they
perform safe operations on local data, and use modern libraries for the
generated data structures (org.json:json and the org.w3c.dom package,
although it's not very user friendly).
On 12/04/2016 07:57 AM, Michael Osipov wrote:
> Am 2016-12-02 um 10:01 schrieb Claude Brisson:
>> Hi.
>>
>> On 01/12/2016 21:21, Michael Osipov wrote:
>>> 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.
>>
>> I'm well aware of this MVC design paradigm. But the underlying purpose
>> is the separation of concerns, not the fact that the view should be fed
>> its data like a baby. View layers have grown up, and pull models have
>> proven their efficiency. Since they are more lightweight and flexible,
>> they are far more maintainable.
>>
>> More specifically, let say for instance that someone wants to build a
>> webapp and a native mobile app on a common model layer. He would
>> typically publish his model in the form of an API returning JSON
>> structures. They cannot be called low-level, because the raw data model
>> has already been somehow digested in the API presentation logic. Each
>> API author is trying to guarantee minimal ergonomics. So if I have, say,
>> the following JSON:
>> { '"books" : [ { "author": "Lewis Caroll", "title": "Alice in
>> Wonderland" } , { "author":"Saint-Exupéry", "title":"le Petit Prince"
>> } ] }
>> what you're saying is that it's not high-level enough for the view? I
>> can't agree.
>
> I do not consider this good application design unless I see a specific
> case where it truly makes sense. Having a browser/client-only app
> implies using JavaScript, thus Velocity will be a little of use. E.g.,
> Sonatype Nexus does that. Render skeleton by Velocity, rest is done in JS.
>
> In this very example, this is not high-level. High-level for me is a
> complete abstraction of the serialization format, Java structures only.
> Pretty much like with Eclipse MOXy or Jackson, they support multiple
> formats and the templater user/designer does not really care about the
> format.
>
>>> 2. You are turning a template engine into a scripting engine which
>>> Velocity is not.
>>
>> Since a bare scripting engine doesn't know how to do templating, I think
>> you intended to say that I'm empowering Velocity with scripting
>> abilities. Well... it's already the case. And another thing: I've seen
>> environments where people made a complete mess of their view layer
>> without using a single scripting functionality. My point here is that
>> although we ought to remain attentive to what the language offers,
>> trying to limit the features is not the right way to promote the
>> separation of concerns.
>
> I agree here, my concern is rather not to introduce features which will
> people encourage to abuse Velocity for tasks it has not been designed
> and knowning that their are better suited tools for this.
>
>>> 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.
>>
>> If I understand correctly, you consider that the existing ImportTool is
>> already wrongful. The door is already open.
>
> Unfortunately, it is.
>
>> I already had in mind to disallow absolute URLs in safe mode (which is
>> on by default) for the view versions. This is already the case for the
>> actual XmlTool, but not for the ImportTool. My plan is to homogeneize
>> all that: the XmlTool generic version would be relaxed by my proposal,
>> while the view version of the ImportTool would be restricted to relative
>> URLs in safe mode.
>
> Sound good.
>
>> I totally agree that fetching an external resource is dubious in the
>> view layer of an MVC webapp. But regarding the generic versions, where
>> only absolute URLs make sense, I think it's not our job to try to
>> prevent bad designs for some by refusing features to others.
>
> While this is right, we still should try to promotive well-proven and
> predictable approaches for the use of Velocity.
>
>>> 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!
>>
>> It's bad design. And you're story illustrates something: if we don't
>> provide people with such tools, they'll write them and it will be worse.
>
> That's absolutely true, though functionality should be still limited to
> avoid frustration and unnecessary support from us.
>
>>>
>>> In that spirit, keep the tools as simple as possible and as offline as
>>> possible.
>>
>> Tools should do their job. That's the spirit. Their syntax and their use
>> should be kept as simple as possible, but I really don't see why they
>> shouldn't do complex things. I wonder how you'll react the day I will
>> want to integrate Velosurf as a ModelTool in a future version...
>
> Just checked Velosurf, really sick stuff (meant positively).
> Velosurf isn't probably the best name for that because it says not much
> about its objective. I am quite certain that there is a usecase for that
> where you have some command line tool to auto generate data from a
> database, but not from a web application from my point of view. It
> pretty much defeats any time of encapsulation and testing capabilities.
>
> At the end, Velocity is a general purpose template engine, there are
> tools which make sense in a web environment and which in a different
> mode only.
>
>>> 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.
>>
>> You may be right here, and that would be more easier than use DOM4J
>> shading, but I'm not sure at all I'll find the time and motivation to
>> rewrite the XmlTool.
>
> You should at least track that as a JIRA issue.
>
>
> Michael
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
