Re: Any plans for a 100% wm syntax compatibility?

Demetrios Kyriakis wrote:
> 
> Jonathan Revusky-3 wrote:

>> #foreach ($i in [1..5])
>>     #alias("World")
>>
>> #end
>>
>>
>> Parameter bar unspecified.
>>
>> etcetera.
>>
>> Well... this is all such junk... 
>>
> Yes, it is junk, but in our case, the users (non-programmers) don't write
> macros, and only use a few
> predefined ones in thier "more text"-oriented templates.

That may be. However, having it work sensibly would not make Velocity 
any more difficult for that kind of user.

> Jonathan Revusky-3 wrote:
>> I googled a bit for some discussion of 
>> this and quickly found:
>>
>> http://wiki.apache.org/jakarta-velocity/MacroIssues
>>
>> The whole thing is just completely FUBAR'ed. What's interesting about 
>> this is that these guys maintain pages like the above one, but then 
>> don't ever draw the obvious conclusion, which is that if they really 
>> want to have a product of some kind of decent quality, they need to 
>> rewrite the parser.
>>
> I think, in order to draw conclusions, one needs to understand the thing,
> but since the original authors are all gone, ... :).

There is a whole film genre, I guess the post-apocalyptic genre, things 
  like Mad Max, Planet of the Apes, Waterworld.... What is left of the 
world after the apocalypse (typically nuclear) is then inherited by 
grotesque mutants or clever apes (the Velocity community definitely 
comes to mind here). Anyway, these survivors of the apocalypse eke out 
their existence among the remnants of the former great human 
technological civilization. They often don't quite understand what these 
things are. Like, IIRC, in one of the planet of the apes movies, 
remaining humans have developed a religion around and worship an object 
that turns out to be a nuclear missile or some kind of doomsday machine.

>> But.... even if this bridged thing is better than Velocity, it is so 
>> inferior to using FreeMarker itself, it's not funny. No namespaces, no 
>> local variables, no macros with blocks, no visit/recurse machinery for 
>> processing XML, no built-ins....
>>
>>From a programmer's point of view you are right, but for the non-programmer
> user all
> those concepts are not important. They only care about the simple syntax
> (V.. happens
> to have).

Well, the fact of the matter is that if you use FreeMarker as if it was 
Velocity, the same feature set, it is not particularly more difficult -- 
if at all. And if it is more difficult, it's pretty marginal, it's not 
like the difference between Visual Basic and Java, say.

It amounts to having to write:

<#if x=y>...</#if>

instead of #if ($x==$y)....#end

or <#set foo="bar"> instead of #set ($foo = "bar")

I admit that the opening and closing <..> could seem more difficult, but 
we're talking about people who are already editing HTML, aren't we?

> Jonathan Revusky-3 wrote:
>> Who would be interested in this? Why wouldn't they just use FreeMarker? 
>>
> Because of the V.., (better said  *.wm)  syntax. 
> It is of course very primitive, but for the non-programmers already the
> upper limit they're able (or ready) to learn.

Do you actually have any empirical evidence for this? It may be true 
that if you went through the whole thing of training them to use 
Velocity syntax, then telling them to forget all that and retraining 
them to use FreeMarker could meet with resistance. But if you had used 
FreeMarker from the start, you wouldn't have that problem. Also, we do 
have a pretty good quickstart guide for non-programmers, I think.

> "Less is not more", but just what they need (and feel confortable with).

But surely they feel comfortable with it mostly because that's what you 
taught them to use. If you'd taught them to use FreeMarker or something 
else, then by now, they'd be comfortable with that, wouldn't they? (As 
long as that something else wasn't XSLT or something like that, 
obviously...)

I mean, if you only taught them the features of FreeMarker that 
correspond to Velocity functionality, it would be about as simple.

Anyway, what you're telling me simply does not ring true for me. To my 
mind, frankly, you're trying to defend a poor decision made in the past 
(to use Velocity) with very weak arguments. Don't take that statement 
too personally, since it's just human nature. I've done (and will do in 
the future) similar things, I'm sure.

In my honest experience, people do not prefer dumbed down tools. Any 
time I go to someone's house to help them with their computer, I see 
that people all use the full version of Microsoft Word and often Excel. 
Almost nobody uses the stripped down Microsoft Works (that often comes 
with the machine, and the Office they have at home is a pirate copy 
usually). For ten years or so, "visionaries" have been predicting the 
demise of the PC, the "fat client". But the fact is that thin client 
sorts of products have, for the most part, been a fiasco commercially, 
WebTV etcetera... People who only surf the web and write the occasional 
letter, who, in principle, should be happy with a thin client, all these 
people buy PC's, something that is much more difficult to use and 
maintain. Also, that's what companies put on people's desktops.

Almost none of these people I'm talking about are programmers.

So, to me, the basic argument that you're making, that non-programmers 
are demanding that you provide them with a dumbed down tool does not 
ring true to me.

> 
> Jonathan Revusky-3 wrote:
>> I have heard nothing from the guy who supposedly wanted this. An 
>> interesting experiment nonetheless.
>>
> Sorry, but I'm not ready with the tests I promissed.
> I'm working on a compatibility test suite (and I had to start with the
> documentation first to get the approval :) ).
> It is not bound to this velocity bridge, but it's generic to use with any
> framework that could produce
> compatible results with Velocity, so that when it's there, with minimal
> effort to be able to test that compatibility.

Well, this will read any velocity template because it uses the Velocity 
parser. The problem is that the semantics are different. If you give it 
a misspelt variable name, it throws an exception. Of course, it's not 
hard to configure it to get the Velocity behavior, but that's a very bad 
idea... there is not complete drop-in compatibility. You have to 
understand that.

> 
> Jonathan Revusky-3 wrote:
>> I think it could be interesting to work up an alternative parser for 
>> that syntax and offer it. Also, by breaking out the syntax like that, it 
>> would clean out a lot of FreeMarker's basic design. So it's an idea... 
>>
> Of course, this sounds much better since than the V.. dependency would
> be 100% gone :).
> 
> 
> Jonathan Revusky-3 wrote:
>> but I don't think that a crippled FreeMarker that uses Velocity syntax 
>> is really very appealing.
>>
> I suppose this is because you think all the time like a programmer :).

I don't think so. I believe I'm thinking like someone who wants to 
create a capable tool for people to use, and I'm quite aware of the 
issue of appropriateness for the audience. And what I was talking about 
is completely orthogonal to this. I was saying how utterly botched 
Velocity macros are. Having the macros work properly would not make 
Velocity any harder to use.

> If you would have to deal with non-programmers (and thier number is much
> higher than ours) you would quickly see where are their limits :).

Has it occurred to you that it's not their limitations as users that is 
the problem but rather your limitations as a teacher or trainer? :-)
Seriously, I have no idea regarding the level of the users of your 
system, so I can't really say. And anyway, the above is posed as a 
question, I'm not saying one way or the other..

Anyway, though it has other use cases, the primary focus of FreeMarker 
is as a professional tool to use in web application development. If you 
look at the range of tools, mini-languages basically, that front-end 
people need to have some familiarity with -- HTML itself, Javascript 
with Dynamic HTML, Cascading style sheets...  -- within that range of 
things that such people are basically expected to know, FreeMarker is 
not especially difficult. Maybe it's not especially easy either, but 
it's within the range of those things that people are basically expected 
to be able to deal with.

The whole argument that Velocity has some advantage on the basis of 
simplicity does not ring true to me. Just as you can use HTML and CSS to 
do basic things without knowing everything about them, you can pretty 
quickly learn a subset of FreeMarker to do basic useful things. And we 
have a pretty good quickstart guide to get people going. And then the 
difference is that when eventually you want to do something more 
complex, you can. You haven't painted yourself into a corner by choosing 
the dumbed down tool.

As I observed above, people do not typically (at least within a 
reasonable range) opt for the dumbed down tool. They use Word. They 
don't use Wordpad or Microsoft Works. In any case, defending simplicity 
as a great advantage of Velocity simply provides those people a 
rationalization for doing nothing. It is an argument that they do not 
really make in completely good faith.

AFAICS, the problem is not that your users opted for the more dumbed 
down tool. The problem is that you, in your superior programmer wisdom, 
made the decision (the wrong one) for them. I think that's what really 
happened and you're providing a completely distorted construction of 
reality.

JR


> 
> Demetrios.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace