CAN WE PLEASE CUT OUT THIS CRAP!! Jonathan, I'm sure you're a nice fella, but you obviously have plenty of time on your hands to exhaustively answer EVERY possible slight that you perceive being directed at you or your beloved FreeMarker. But pleeeeeeeze, give it a rest!
Your emails are provocative, lengthy and nearly always non-technical. You're more interested in beginning on about the merits of FreeMarker over Velocity than you are in contributing code to Velocity. Reading your emails is like drinking Youngs at my rugby club on a Saturday night - I know I should go home and cook dinner, but as I see another beauty being poured I just can't resist another little delve! Just like reading your missives, I feel guilty afterwards for wasting so much of my time......... Apologies to everyone, yes I'm the guy who started this whole bloody thread "WHY VIENTO!!" Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Revusky Sent: 13 October 2005 15:21 To: velocity-user@jakarta.apache.org Subject: Re: What's the ideal syntax? Was: [ANN] Viento - WHY? Christoph Reck wrote: > Hi Jonathan, > > since you are eager to understand how Velocity is progressing, you can > see that Velocity is not a one-man-thing, but a team of lead developers > and other contributors spending some of their time to test patches, > implement requested features and to answer user questions on the > mailing lists. One main goal seems to be the do-it-right and professionally > (with a slower progress than in the main bread-and-butter jobs), as well > as ensuring backward compatibility. Though this is veering into a meta-discussion, I cannot help but make a few comments of the "meta" nature. When I read the above at first, I was naturally irritated. There is this level of insufferable pompous posturing -- "we are such professionals blah blah" -- that I find to be extremely provocative. I initially perceived this as a form of aggression or provocation. And then, this lead me to wonder whether the intent, in fact, was to enrage me, and get me to say something immoderate in response. (And that, in turn, would give the yahoo elements here something to sink their teeth into.) But actually, I don't think you're that Machiavellian. This kind of empty, pathetic posturing is probably just something reflexive at this point. It seems to be the norm in this community. Since you guys do seem to function in your own kind of crazy bubble, I guess you don't have a sense of just how preposterous it would seem to any outside observer. As such, you are casting yourself in a somewhat ridiculous light, and you might be doing yourself a favor to take that into consideration... Anyway, all this stuff about what great professionals you are, in the context of basic features simply not being implemented, sort of begs the question. If the progress you are detailing about this whitespace issue is typical of the professionalism of this project, then maybe what you need is some unprofessionalism, then maybe you could get some things done! :-) > > The fact that Velocity has a large user comunity lies on the simplyness > and beauty of the approach. It is very useful as it is. Some enhancement > would raise its usefullenss, and these are finding its way in, mostly > in a BC form. Well, Christoph, the above statements are entirely vacuous. The _approach_ of Velocity may well be "simple" and "beautiful", but not more so than any other template engine. The basic idea of a template engine is, in fact, simple. Now, Velocity may well be "simple" in the sense that it lacks many features that a more powerful tool like FreeMarker has. However, to suggest that people performed a duly dilligent comparison of these tools and opted for Velocity because it is _lacking_ in various features does not really ring true. Do you believe this? After all, it doesn't bear close scrutiny, since, if you just use FreeMarker in the exact same way that you would use Velocity -- not leveraging any more advanced features -- it is not any less simple than Velocity. Meanwhile, just look at the workarounds being proposed for Velocity's complete failure to handle the whitespace issue. This definitely does not make for simplicity. Solutions involving underpowered tools for a job will typically be more complex than those that use an appropriate tool. The horrendous workaround for the whitespace issue that you admit that you use is just one such case. > > The proposal for the whitespace gobbling for structured templates was > made by me in 2001. Hmm. Well, that is a while ago, seeing how 2006 is just round the corner,... Christoph, I cannot easily imagine that you are not at least somewhat disappointed by the lack of progress on this. However, you do not react in what I would consider a normal way. If you feel disappointment about this, you seem to be quite unwilling to express it. You seem to want to represent that this is completely normal... "we're all fine professionals making sure to take the time to 'do it right'...." Well, how much time is reasonable? > The escence was finally taken up into an issue > http://issues.apache.org/jira/browse/VELOCITY-253 > And the different approches and community requets where summarized > in the wiki: > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling > > With the scheduling features in Jira and Will having taken the lead, > it has been scheduled for a 2.0 release when some non-BC formatting > changes would be possible. > Well, isn't backward compatibility just being used here as a mantra to rationalize the fact that nothing has been done? If the above referenced proposal is how whitespace *should* be handled by Velocity, even if the changes are not completely backward compatible, is this a reason to dawdle? I mean, whatever transitional cost has to be assumed at some point anyway, so why not bite the bullet sooner rather than later? Also, the value of 100% backward compatibility in new versions can be overstated IMO. After all, a user always has a guaranteed way of having complete backward compatibility, which is not to upgrade their existing version. The existing version is useful as-is, as you point out above. Moreover, anybody totally paranoid about breaking existing code will be very slow to upgrade anyway. > I also suggested that the parser should not gobble any whitespaces, > and then add a postprocesor to the AST implementing the desired/configured > gobbling schema! This is, in fact, how I implemented it in FreeMarker. There is a routine that walks the parse tree after parsing and does the whitespace adjustment. What is interesting here is that, with this disposition, there is no backward compatibility issue, since the post-processing of the AST can be optional. In FreeMarker 2.2.x, the whitespace stripping was a toggle you could turn on, and then in 2.3.x, it was on by default, and you had to explicitly turn it off. By the way, here is something that could be of interest to you. You know how many complaints we got from users about the fact that FM (as of 2.3) was stripping all the extraneous whitespace by default? Zero. Zilch. Nada. Nichts. Though it's theoretically not backward compatible, it would seem that nobody missed all that extra whitespace in the output anyway. So, if you want to benefit from the experience of our community (and why shouldn't you?) our experience suggests that the backward compatibility implications of this are, in fact, an ersatz issue. > > The implementation for such a change is far from trivial, being a rework > of the parser, and will affect BC. Yes, the implementation is far from trivial. I would know. You do realize that, of all the people who are involved in this thread, there is exactly one who has implemented this whitespace behavior in code. Me. It was a bear to implement. Of course, as I said, our community also has the experience of whether the backward incompatibility that this entails is a problem in practice. I think it's safe to say that it is not. > > It is an open community, and anyone who is interested can jump in > and supply a patch. > > Personally, if someone reworks the parser to be non-whitespace-gobbling, > I would be eager to then provide the structured template gobbling > implementation patch! If somebody else does X, then you'll do Y. Okay, but on this business of professionalism, is this level of attachment and sentimentality to tools really very professional? For several years now, there is another tool that has the whitespace behavior you want. Wouldn't a true "professional" just use that rather than insist on using something that does not have the feature he clearly needs, and, to all outward appearances, given the lack of action in 4 years or more, may *never* have the feature in question. I asked you whether you considered it somehow improper or unfair for me to tell people -- in the context of a thread on the subject here -- that FreeMarker has this whitespace removal behavior as described on your wiki. I reason that there is nothing improper or unfair about it. People with a professional attitude would surely be grateful that I inform them that a tool they may not have been aware of has the feature they need. So, Christoph, do you consider it somehow improper for me to tell people that FreeMarker has the feature in question? (If you do, I would want to know on what grounds...) Regards, Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org > > :) Christoph Reck > > > Jonathan Revusky wrote: > >> Christoph Reck wrote: >> >>> Hi, >>> >>> the whitespace issue has been debated quite a lot, and we have a >>> consensus in this list that we will implement in the future a >>> gobble-none and a gobble-structured form; >> >> >> >> That is interesting to hear, Christoph. >> >> I'm still a bit vague on the details. >> >> When did all this debate occur? >> >> What is currently the status of implementing this? Has somebody been >> assigned ownership of the issue? >> >> Is there some roadmap which says approximately when a future Velocity >> will have this? (I do not recall it being in the list of things to be >> in 1.5.) >> >> <snip> >> >>>> >>>> #if $(user.isAuthorized)#* >>>> *#Hello#* >>>> *##else#* >>>> *#Good Bye#** >>>> **##end >>> >>> >>> >>> >>> that's what I'm doing sometimes now, and it's yuck to mainatin! >> >> >> >> Well, I sympathize with that, it really seems terrible to me. OTOH, >> are you obliged to use Velocity for these purposes, company policy or >> something? >> >> Because if not, obviously, obviously I know of one better alternative >> available. (Guess which one? ;-)) But there may be others. I have not >> done a survey of the template engine field recently. >> >> >>> >>>> >>>> But is this reasonable? >>>> >>>> Again, the fact that it is possible to achieve precise control of >>>> whitespace is not the key point. It is that you want such control >>>> while having a reasonable, human-readable template. That is the >>>> raison d'être of templates really. >>>> >>>> Okay, I guess no Revusky posting would be complete without a >>>> FreeMarker plug. The FreeMarker solution was to introduce whitespace >>>> trimming directives that are applied at parse-time. >>>> >>>> So, in FreeMarker, you could write: >>>> >>>> <#if user.isAuthorized> >>>> Hello<#t> >>>> <#else> >>>> Good Bye<#t> >>>> </#if> >>> >>> >>> >>> >>> That is exactly in the line of: >>> >>> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbleStructuredTemplates >>> >> >> >> >> >> >> Well, except that there is an important practical difference: this is >> the way FreeMarker actually works, has been working for the last >> couple of years at least. Meanwhile, you are pointing to a document >> that says: "wouldn't it be nice if Velocity worked this way?" It is a >> significant difference in particular when somebody needs this to be >> working today, not at some unspecified date in the future. >> >> Earlier, I probably infuriated people here by saying that "if you talk >> the talk, you should walk the walk." But this issue seems like yet >> another case in point. If, in the Velocity community, for all the talk >> or debate, there is not the gumption to sit down and do the work of >> implementing badly needed functionality, and if, in our community, we >> have done the work of implementing the feature that many people need, >> why should I refrain from telling people this when they specifically >> query about this? Especially when many people who could benefit from >> our work may not be aware of it? >> >> So, when I have said that if you guys talk the talk, you should walk >> the walk, you do see my point, don't you? >> >> It seems fair to say that, at least for people who have no significant >> investment in Velocity, if they need or may need fine control of >> whitespace, they should look elsewhere. >> >> Would you disagree with that, Christoph? >> >> Regards, >> >> Jonathan Revusky >> -- >> lead developer, FreeMarker project, http://freemarker.org/ >> >>> >>> >>>> >>>> The <#t> directives indicate that the opening and trailing >>>> whitespace on the line is to be gobbled, i.e. it is there to make >>>> the template human-readable. (There are also whitespace gobbling >>>> rules that say that the if else and the closing tag, since they >>>> occur solely on a line with no other whitespace output, gobble their >>>> opening and closing whitespace.) >>>> [snip] >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
