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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
