Jeromy Evans wrote:
I have been of two minds whether to pursue this conversation and make
certain points. I strongly disagree with some of things you're saying
here, so, finally, I'll just make the points that I think need to be
made on this topic. I don't think there's a need for any further debate
about any of it. It seems you do recognize that the quote on the page in
question is outrageously misleading, and should be remedied.
One thing I'll say up front is that I can't really look at this as a
favor to me or our community. You should be doing this because it's
what's in the interest of your user community and just the general
public out there.
Jonathan Revusky wrote:
Thanks for the detailed argument Jonathon.
Jeromy Evans wrote:
Niall Pemberton wrote:
I just saw the following comment
"FreeMarker is very similar to Velocity, as both are template
languages that can be used outside of a Servlet container. The
framework utilizes FreeMarker because FreeMarker has better error
reporting. However, both are good alternatives to JSP."
I've questioned that a few times myself. The paragraph doesn't do
FreeMarker much justice from a technical sense, but then again, most
Struts 2 users won't exploit the features FreeMarker offers above
Velocity,
What is your basis for thinking this? It's clear enough from the
freemarker-user list that people do use advanced features of the tool
that are not in Velocity. I just don't see offhand why the usage
patterns of people using FreeMarker in conjunction with Struts 2 would
be particularly different from users in general.
Though, the other thing is that, even if the assertion were true, I
don't know how you would know it was... it seems like a seat of the
pants conjecture...
The basis of my conjecture is that Struts 2 provides little support for
FreeMarker's more advanced features, so most users won't exploit those features.
To me, this makes little sense. It would seem that we have completely
different conceptual models of what is going on here. From my
perspective (though maybe I am the one mistaken...) you have certain
fundamental misconceptions.
There is basically no need for a framework like Struts 2 to explicitly
support FreeMarker's more advanced features. They're just there if
needed. Translatinf this idea to a JRuby result or a Groovy result. we
could say that if the front end coding is in Ruby, the view could use a
very small set of Ruby's language features or a much larger one. But
that has almost nothing to do with the controller used. And the same
applies to the use of FreeMarker's template language. Whether a project
makes very sophisticated use of FreeMarker's macro capabilities would
depend mostly on the project's requirements (and also on the
skill/experience level of the front-end coders) not on whether the
project was using Struts 2 or Stripes or Spring MVC, say.
You see, the fundamental usage pattern is that you expose your data
model to a page template and produce output. In terms of using
FreeMarker, how the data got to the template layer (whether it was put
there by Struts 2 or by Stripes or whatever) is irrelevant and doesn't
have anything or at least very little to do with the complexity or
sophistication of the templates.
As regards more sophisticated uses of templating, I was thinking about
this a while back and wrote a blog entry with some (possibly
wooly-headed) ideas.
http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html
The above is worth reading if you want to understand my perspective on
this sort of thing, and some of the thinking behind FreeMarker.
The model provided to FreeMarker is a map containing the request,
response, ValueStack and a few other basic structures, where access to
the ValueStack (Struts2's core model) is limited to Struts2 tags to in
order to access OGNL. I don't know the history, but it appears the
FreeMarkerResult[1] was designed to be equivalent to the Velocity
implementation rather than to exploit FreeMarker features. Similarly,
although the Struts 2 tags use FreeMarker templates, the model is
limited and the templates don't encourage what I think you'd consider to
be best-practice.
My conjecture still stands, that "as built", most Struts 2 users won't
exploit FreeMaker's better features. That's not meant as a criticism of
FreeMarker.
Take a quick look at the source:
[1]
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/views/freemarker/
[2]
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/template/css_xhtml/
Well, I provided the link to a discussion of FreeMarker vs. JSP from
Jive Software developers. Jive's product is built on top of Webwork and
FreeMarker. One of the points made in there was that Velocity simply
wasn't powerful enough for their needs. Again, it's only one data point,
but it supports the idea that a sophisticated web app built on top of
Struts 2 may very well need the more powerful templating tool.
But as I said above, the fundamental usage pattern from the FreeMarker,
or really, templating layer perspective, is the same old same old. There
is a data model exposed to the template and it doesn't matter where that
data model came from really.
....
FreeMarker is technically superior in (almost?) every way, but not
always appropriate.
I have heard this before, but I cannot conceive of a usage scenario in
which Velocity would be indicated over FreeMarker. In terms of JSP,
that has the obvious advantages associated with being a standard,
greater tool support, more people out there who already know it. That
said, there are plenty of people who prefer FreeMarker. The reasons
vary, but I think they just find that it's a a lot cleaner...
conceptually, I guess. As for things like JRuby or Groovy results, I
think that is something so different that a direct comparison with
FreeMarker or Velocity doesn't make much sense.
I agree with most of your statements but there are many cases where
technically superiority does not mean it is the most appropriate
solution. Perhaps you have the good fortune of only working with
experienced java developers and don't have to trade-off development
costs, but the learning curve, familiarly with the syntax and tools
support are issues that do exist and are impediments to the take-up and
cost-of-development with FreeMarker.
Given the mix of things, mini-languages basically, that the front-end
coder needs to master nowadays to do web development, the idea that
FreeMarker is especially complex relative to all that, just does not
ring true to me. If we were talking about XSLT, which is genuinely quite
difficult, at least for most ordinary mortals, that would be another
matter, but the argument that FreeMarker is complex in this basic range
is something I find unconvincing, to say the least.
OTOH, of course, I am not saying that FreeMarker is the appropriate tool
in all situations. It probably isn't. Though it is pretty appropriate
across a very broad range of typical scenarios of developing web apps in
java. I would even venture to say that it would almost always show up in
the short list of tools to consider seriously for the presentation layer.
My honest belief is that Velocity would basically never be appropriate
to recommend in these same scenarios. There are two basic reasons for that.
(1) Velocity is simply too dumbed down. It is missing basic features
that should be considered must-have for a web page templating tool. Just
offhand, I am thinking of things like transparent support for
internationalization, auto-escaping of interpolations, so that
problematic characters are converted automatically, reasonable support
for maintaining libraries of macros to encapsulate presentational
elements... As for the i18n, say, even if the initial requirements are
for a web site in English only, say, it is very hard to know if that
will not change in the future. It would be very easy to imagine that a
client, after a successful launch of a product or service in the U.S.
would reason that the same basic business idea would work in Europe or
elsewhere, and then i18n would be a big deal. It is basically just not
good to paint yourself into a corner on basic things like this.
So, the first point is that Velocity should not be recommended or
endorsed, because it is simply not powerful enough, at least in the
general case. The blog entry I wrote about this, "Velocity vs.
FreeMarker, looking at 5 years of Practical Experience" is largely (but
not solely) about this aspect of things. In that vein, you could look at
what the Jive developers have said, or what Matt ward said in the blog
entry I linked earlier...
(2) Even given the dumbed down feature set that Velocity provides, there
are enough first order problems due to the poor design and
implementation of the tool to reject it pretty much out of hand. IOW,
I'll assume, for the sake of argument, that you know for 100% sure that
this limited set of features is all you need. (*And* all you will *ever*
need. Of course, how do you know that for sure? But, okay, I'll assume
we know this...) Even making that assumption, there are enough problems
in terms of the design and execution of the tool that it is not to be
recommended.
I think the foremost evidence for this is Max Anderson's blog article
where he talks about why he had to switch away from Velocity. The
biggest problem was the lack of error reporting. He simply could not get
Velocity to tell him where he made a mistake. Some improvement was made
in this since he wrote that, but we're talking about a situation where,
5 or 6 years into the existence of the Velocity project, it lacked
something that basic. If you've just got a mock-up prototype and you
have one or two very simple templates, that is one thing, but a large
production system with many complex templates, that simply will not tell
you the line number or even the file in which you made a mistake.. And I
could get into all the various problems with how macros are implemented
in Velocity (there are people who've been there, done that, who know
what I'm talking about) but this really is not something that should be
recommended to people for heavy duty professional usage.
The approach of the page that was cited in the starting post of this
thread is basically to give the nod to FreeMarker, but say that both
FreeMarker and Velocity are valid options for templating. And I see that
as pretty misleading.
We should link to/provide something that helps users decide what best
suits their circumstances,
Anything you link to would be just somebody else's opinion. There is no
reason that you could not offer your own opinion. I'd infer that you
don't want to point out there that a fellow ASF project is abjectly
inferior, so, okay, you provide a link where some 3rd party says it,
but you know.... ;-)
I'm not sure if biases exist like that; the PMC would have to comment.
I've never noticed anything like that, especially with Struts2's heavy
dependency an opensymphony projects and the project's core dependency on
FreeMarker.
This is a tangent, but I do have to point out that the above is not data
that really supports your postion. The reason that Struts 2 makes such
heavy use of opensymphony projects is because Struts 2 is a continuation
of Webwork, which was part of opensymphony. In fact, it supports what I
was saying, that the project under the larger umbrella has some amount
of bias towards the other projects in that "family". Actually, that's
probably normal, and is not something I would really have a problem
with. I think it becomes a problem in the case of projects that are as
uncompetitive in their space as Velocity. Telling people that something
in that kind of obsolete, pretty much abandoned state, is a valid
option, does not strike me as even being a very ethical thing to do.
I'm expressing a personal opinion, which was that
FreeMarker is technically superior but not always appropriate. I
personally would rarely choose Velocity, but I also can't recommend
FreeMarker with a broad-stroke.
If the focus of the conversation is FreeMarker vs. Velocity, I do not
believe that any informed person could ever really recommend Velocity.
That is my honest belief. And the quote in question was specifically
about FreeMarker vs. Velocity.
including the argument for and against JSP. I don't think there will
ever consensus to recommend one.
I think that in terms of FreeMarker vs. Velocity, there is a pretty
strong consensus among technically informed people in favor of
FreeMarker. As for JSP or other things, like XSLT maybe, or Groovy or
JRuby, they aren't directly comparable in the same way that FreeMarker
and Velocity are.
They're comparable within the context of Struts 2 at alternative
approaches to implement the action or result. My point was to encourage
Struts 2 users to consider the most appropriate solution instead of
focusing on a particular technology.
Well, I'm sorry, Jeromy, this, to me, seems like an irrelevant tangent I
mean, car enthusiasts can have a very focussed conversation about
whether a car made by Toyota is a better or worse choice than a
comparable model from Volkswagen, say. They could inject into the
conversation a comparable model from Ford or Citroen. That would broaden
the conversation somewhat but it would remain focussed, because it would
still compare things that were directly comparable. If you started
talking about whether the person would be better off riding a bicycle or
taking the bus, you get into a more general conversation that might even
be more interesting in a way, but that conversation is unlikely to
arrive at any specific conclusion and would not have the same technical
focus. In fact, bringing the bicycle and public transport into the
original conversation does serve the agenda of derailing that
conversation's more concrete technical focus by going off on a tangent.
This thread (and I didn't start it) is about this kind of narrowly
focussed question of comparing two tools which embody the same basic
paradigm and are clearly comparable.
At the same time it may be useful to compare these to why a
JRuby-based or Grails-based action/result may be more suitable. Blog
anyone?
Well, again, you're bringing in things that aren't directly comparable
in the way that FreeMarker and Velocity are. And that was the topic at
hand. Limited to those two things, the case for FreeMarker is just
devastating, I think. It is not an objective source obviously, but I
think the following covers the points:
http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html
And it's not unfair to link it, I suppose, because if the Velocity
people cared to write a rebuttal, they have the right to, and you
could link that as well. That blog article contains links to some
other blog articles detailing a switch from Velocity to FreeMarker.
http://in.relation.to/Bloggers/AStoryAboutFreeMarkerAndVelocity
http://blog.nominet.org.uk/tech/2005/06/29/moving-from-velocity-to-freemarker
http://blogs.sun.com/satya/entry/migrate_to_freemarker_from_velocity
Of course, you could say that the above ones are cherry picked to
support the case for FreeMarker. But actually, go look for similar
blog articles about a move in the opposite direction. You'll come up
empty handed, I dare say.
Oh, and as for FreeMarker vs. JSP, Jive Software, whose flagship
product is built on Webwork 2 and FreeMarker, switched from JSP to
FreeMarker. Here is some discussion by the Jive developers on that.
http://article.gmane.org/gmane.comp.web.freemarker.user/2984
http://www.jivesoftware.com/community/blogs/clearspace/2007/07/20/the-switch-to-freemarker
Note the last point Bruce made there on our mailing list: "It's
powerful enough for our needs -- velocity didn't have the features we
required." This does seem to contradict the idea that Struts 2 users
would not need the extra power that FreeMarker offers. Just one data
point admittedly, but it tells you something.
Well, 'nuff said, I guess. In some private conversation, one of my
collaborators on FreeMarker pointed to the quote above on your site
about FreeMarker vs. Velocity and, you know, basically said that it
was highly annoying... there's a strong sense out there (right or
wrong) that something like this is an example of you bending over
backwards to be charitable to a fellow ASF project. I had seen that
page before and that was my impression as well. I dunno... Do what you
want, but I don't think you're doing anybody any favors by holding
back on telling the unvarnished truth about this kind of thing. I
don't think that it's even a favor to the Velocity community, though,
you know, if some of the blogs I have linked never shook them out of
their complacency, I don't know what would... :-)
Jonathon, you're preaching to the converted. I think most Java
developers that have used FreeMarker prefer it to the alternatives for
the reasons you've mentioned. The technical argument was won long ago.
Well, among the people who know what is going on in this space, yes. At
least increasingly so. But it has taken a very long time to reach this
point. Years.... and still, it's still more or less the vanguard, let's
say, the web app cognoscenti... for whom the argument is over. Once we
start talking about the rank and file of developers out there, it's not
that obvious. In fact, this is such a key point that I'm going to shout it.
THEY JUST DON'T KNOW... THEY DON'T HAVE A CLUE!!!
And that is a key thing going on. I really don't want to get into this
again, but it is, quite honestly, the best example I can think of to
illustrate my point: Why was it such a brilliant idea to rename Webwork
as Struts 2? I mean, people that had investigated the matter knew
perfectly well that Webwork was better than Struts, so why rename the
superior product with the name of the inferior one? That would seem to
make no sense.... except for one thing, which I will again shout:
THE PEOPLE OUT THERE, BY AND LARGE, DON'T HAVE A CLUE!!!
I mean, they just don't.... if they did, renaming the superior product
with the name of the inferior one would just make no sense...
I think it's fairly well known out there that I have something of a chip
on my shoulder about these various related issues. It is my considered
opinion that if ASF were a better run entity, a project in the state
that Velocity is in (and has been for years) would have to put up a
front page, saying "Hi, I'm an abandoned, obsolete project. If you're
interested in adopting me, here is how would you would go about it..."
Given the brand name projection that ASF has, and all the people who
look to ASF as some kind of open source authority to be trusted, it is
totally unfair to be projecting the message that something that
technically obsolete, in the state it is in, is actually a valid option
for people looking for this kind of tool. And that, basically, is what
the quoted page does. Okay, it gives the nod to FreeMarker, but strongly
implies that Velocity is about competitive. And that is not something
that is remotely true.
I've had at least one conversation in private that has gone along
similar lines and the other person says that it is up to the people out
there to do their own due dilligence on their toolset, and they have a
point, but I do not find that rationalization fully satisfactory,
because I know, as I said before:
THE PEOPLE OUT THERE, BY AND LARGE, DON'T HAVE A CLUE!!!
And finally, to say that they *should* know, they *should* have done due
dilligence to evaluate different things, and so on, is sort of beside
the point, because in final analysis, it's like saying that if pigs had
wings, they could fly. The premise just isn't true. By and large, people
out there don't know, and they look in particular to ASF as a
trustworthy authority of sorts. (I have no idea why, but...)
Finally, by the same argument, it would be okay to give misleading
directions to a tourist visiting your city, because they should know
where things are, and they should have brought a map and so on... but
anybody can see that that is silly. After all, if the American tourist
in question knew where the Tate museum was, and how to get there, they
wouldn't be asking you for directions, right? If people really knew what
was going on in the templating space, it wouldn't matter at all what you
put on a page like that, because they already know... so it only matters
in the case of people who don't know, so that is obviously the case we
should be talking about...
So, look, to close this, I took issue with various points you made, but
the central A-1-A thing I disagree with is what you say above, that we
won the argument, and implicitly, everybody knows what's going on with
this anyway, and the implication is that the text in question on that
page doesn't really matter. And finally, I think that's 180ยบ away from
the truth.
To be suggesting, at this point, that FreeMarker and Velocity are both
valid options, in this kind of pseudo-politically-correct way is
actually unfair to the general public out there, who just don't know
(independently of whether in a perfectly world, they would all have done
their homework and thus know.... but they didn't and don't...) and also
this kind of thing is unfair to projects like the FreeMarker project
that really are doing the work at the cutting edge in their space.
The next battle is that of wide-spread IDE support and easing the
learning curve for the JSP-focused kids still coming out of uni. Struts
2 has to face similar battles as other frameworks exist that are cheaper
to use or provide better features in any aspect examined in isolation.
Well, Struts 2 has a huge advantage over its direct competitors.
Something like Stripes, let's say, is competing for users and mindshare
on such a non-level playing field, it's not funny. It's as inherently
unfair situation as I could imagine, and obviously I would much prefer a
situation in which things really did compete more on the basis of
technical merit, in which the playing field was more level. I think the
endusers would be better off if things were that way, and also the java
open source world would be a healthier more vigorous place, but... okay,
the world is not that way.
So, okay, I'm tilting at windmills, but it still seems to me, that if,
for example, that Javaworld article that I was reacting to implies that
FreeMarker and Velocity are more or less comparable, when that's not
even remotely true, it is right and proper that I should strenuously
object, and write a rebuttal. And, you know, if people want to demonize
me for calling a spade a spade, that's really not something I can control...
So anyway, getting back to where I started on this, the paragraph in
question is totally inaccurate and misleading, and could easily cause a
lot of fellow developers to waste large amounts of time, and really, it
should be corrected. But OTOH, in the overall picture, it's like a drop
of water in the ocean, and I'm basically inured to it. So, you know,
it's like I write what some people might call a passionate rant about
something like this, but the real truth is that, for me, it's kind of
like water off a duck's back by now...
I understand your sensitivity to FreeMarker vs Velocity debates pbut in
this case all posts were pro-FreeMarker and all caveats were on
non-technical basis.
Yeah, I guess I am hypersenstive about it, but hey, at least I'm in
touch with my feelings... :-)
I'll make sure the dismissive comparison of FreeMarker vs Velocity is
updated as per my original post, including your links to the
"unvarnished truth"..
Okay, I'll say "thank you" in a qualified manner. Thank you. The
qualification is that it should be clear that you're correcting the text
and providing the links because it's the appropriate thing to do for
your users and so on. It's not as a favor to me or even the FreeMarker
community...
Also if you have suggestions for Struts 2 to
better utilize FreeMarker it would be helpful to continue to provide
feedback as I'm certain it's not utilized well.
I'd have to look at it more closely. Perhaps some things in this regard
will come to my (our) attention. There is some spillover from the Struts
2 community to our lists, where people sometimes are asking questions
that are really kind of specific to Struts on the FreeMarker list. I
have to admit that, personally, I barely pay attention to that kind of
question, because typically the most appropriate answer seems to be that
whatever they're asking about is a Struts issue, and doesn't have to do
with FreeMarker. Still, one can get a feel for the usage patterns, and
if something comes to my attention, I'll bring it up. FreeMarker usage
is dominated by the web space, but people use FreeMarker in conjunction
with Spring and Stripes and a whole host of other lesser known
frameworks, and, like I said, I've never really got the sense that
people's use of the tool is radically different based on the framework
they're using. (Though I could be wrong about this...) I guess my
viewpoint is that the main difference would be that there are different
things in the data model by default if you use Stripes than Struts, say,
but from the perspective that I and other freemarker people are coming
at things from, that's... you know, mostly like a secondary detail.
Cheers,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker vs. Velocity, looking at 5 years of practical experience
http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
