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