On Mon, Dec 5, 2016 at 9:49 AM, Sergiu Dumitriu <sergiu.dumit...@gmail.com>
wrote:
> 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 with Claude here. Making powerful tools available is a good thing. If
we were putting this in Engine, i'd protest. Even in VelocityView, clearly
for webapps, it would seem an inappropriate default. But in GenericTools, i
think it fits fine. They are to be generic, useful. Velocity is not just
about MVC, not just used in applications.
> I'm also against propagating the dependency on DOM4J, a library which
> has been dead for ten years.
>
Well, those who do the work should decide, but if i were doing the work,
yeah, dom4j does smell a little. ;) Though arguably we can hardly be too
critical of old, little-update libraries.
> 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
>
>
