The Artima Developer Community
Sponsored Link

Weblogs Forum
What Do You Look For in a Template Engine?

69 replies on 5 pages. Most recent reply: Aug 16, 2007 8:44 PM by Frederick Sickert

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 69 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Dave Webb

Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 23, 2007 6:58 AM
Reply to this message Reply
Advertisement
>
> There's absolutely nothing wrong with your code. I think
> the point is, the JSP API allows developers access to
> *all* layers of the domain (including data access) which
> is a *very bad thing* according to just about everyone
> IMHO.
>
> Curtis

Perhaps a lot of this comes down to the scale of the project.

For smaller projects (which is my domain) you can get away with JSP, as long as you don't abuse it and use it strictly for the presentation layer. In this case, the parts of it that are considered a *very bad thing* aren't a problem because I simply don't go there.

I can imagine it being more of a problem on larger systems with many developers.

Jay Sachs

Posts: 30
Nickname: jaysachs
Registered: Jul, 2005

Re: What Do You Look For in a Template Engine? Posted: Jul 23, 2007 7:01 AM
Reply to this message Reply
> could you detail a bit about the differences between Jamon
> and JSP? After a first glance it looks like the template
> syntax is similar, and both get compiled into Java
> classes. I couldn't find a direct comparison on Jamon's
> website. So far my guess is that your compiler does a more
> then the JSP compiler...

One of the key differences is that each Jamon template (and subcomponent) declares its arguments with types. So invoking a template is type-checked, as is invoking subcomponents. So, for example, a templae could declare that its arguments are an Employee and a Timesheet; to invoke the template, the code would be
new MyTemplate().render(aWriter, anEmployee, aTimesheet)
. Contrast this with JSP, where you pass in an anonymous map. This applies both to top-level templates, and to subtemplates (taglibs in JSP).

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 23, 2007 12:51 PM
Reply to this message Reply
> I'm still a fan of jsp. I find it easier to keep track
> when the HTML and display logic are placed together in one
> file.
>
> As long as there's a clear separation between the display
> logic and the rest of the system, and there's a good
> library for all of the formatting, etc of the page, it
> seems ok to me.
>
> What's so bad about this code..
>
> <%if(user==null){%>
>   Please log in
> <%}else{%>
>   <table>
>   <%for( Item item: MyDB.findItems(user.getId()) ) {%>
>   <tr>
>     <td><%=HTML(item.getName())%></td>
>     <td><%=HTML(item.getDescription())%></td>
>   </tr>
>   <%}%>
>   <table>
> <%}%>
> 

> There are lots of changes and additions I'd love to see
> with JSP, but the bottom line is: it never gets in my way
> as long as I don't abuse it.

Where does one start? :)

* How do I know when/ how there is a 'user' available in the context?

* What is the type of the 'user' variable?

* What happens when I refactor findItems e.g. to take another type of parameter? You won't find out until you actually hit the page, and then for many types of errors only when all the conditions to reach that block are met. It's not that you can't refactor when using JSPs, but it will be more tedious (and more work too).

* No reuse. So you created a fragment of a list of users. If you want to display that list somewhere else, you would either copy 'n paste that, or put that code in a seperate template and use jsp includes. But if there is any input logic behind it, you're out of luck, and you'd also have to ensure that everywhere you use the include, you have the context properly filled. And how do you prevent/ detect that the include is done at a place where the context isn't sufficiently filled? You'd have to find out at runtime right?

* This way of coding gets in your way if you want to work with plain HTML mockups (that could come straight from your design documentation) and/ or when you want to hire web designers (they'll have to know JSP, have to use tools that can make something of it, etc).

* It gives you less options for code exploration.

* Purely subjective, but to me it just looks ugly. And I think aesthetic values in programming are underestimated.

I can make this list twice as long easily, but for me the main reason to dislike code like that is because I know from practice that it doesn't scale for development. It works fine for simple projects, but when projects get larger, it will be very hard to avoid ending up with an incredible mess.

But hey, if it really never gets in your way... all the power to you :)

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 2:22 AM
Reply to this message Reply
About a year ago, I wrote an entry in the FreeMarker group blog about the designer-developer division of labor:

http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html

Basically, I argue there that the whole templating discussion needs a sort of paradigm shift; in the general case, you need to think in terms of 3 basic roles in web development. Once you do that, a lot of the fallacies and muddled thinking kind of get washed away.

I would add here that one basic problem in this whole discussion is the way terms are used in a very unrigorous way -- simple, complex...

Now, simplicity/complexity has one paradoxical aspect in this discussion: using a more powerful templating language, i.e. with more features, that is, in a sense, more complex, may well lead to simpler templates, because the extra language features help you manage the complexity. Similarly, large programs in legacy languages like FORTRAN or COBOL tend to become unwieldy, i.e. complex, not because the languages are themselves complex, but rather, because they are overly simplistic, lacking in key features that are needed to build large systems.

Key fallacy 1: The desire for "simple" templates is not the same thing as the desire for a "simple" templating language. I am pretty sure that there is a range in which having a simpler (less powerful templating language) will lead to more complex templates to solve the same presentation tasks. (Or, alternatively, the complexity gets pushed back into the java code, which is a clearly violation of separation of concerns.)

Terence Parr seems to be quite guilty of the above fallacy in his article on model-view separation. A related fallacy is the notion that having programmatically complex templates necessarily means that you have model-view entanglement. The fact is that simply presenting data sensibly across a wide range of input and usage scenarios is potentially quite complex.

Key Fallacy 2: That your templates are complex does not mean you're necessarily doing anything wrong. The complexity is there, and is in the nature of the problem space. The issue is in managing the complexity. Pushing the complexity into your java code is obviously not the solution, since that clearly does violate separation of concerns.

Terence also sets up certain straw-man positions that are also reflected in this blog entry. He seems to imply that normal use of a popular template engine such as freemarker involves the template actually mutating domain objects. This is really about 180 degrees away from the truth. Now, the potential for this exists insofar as the application can expose java methods to the view. And those java methods can, in principle, do anything. But similarly, you can argue that the potential exists for a template engine such as freemarker to reformat your hard disk -- assuming that somebody exposed a method to your template that does that. But that's silly, right?

The fact is, the normal usage pattern espoused is that the data model exposed to a freemarker template is immutable. For example, when you write [#assign x = "y"] in a FreeMarker template, you are not altering the data model. If there is a variable named x in the data model, you are simply hiding it (due to scope resolution rules) by defining a variable x in your template, you are not altering the x in the data model. In fact, you can still get at the x variable defined in your data model via ${.data_model.x}. FreeMarker has no built-in syntax for assigning variables within the data model For example, something like [#assign foo.bar = "blah"] is not even valid FreeMarker syntax. To allow the template writer to mutate the data model, you really need to go out of your way to expose special methods that do it. By design, FreeMarker makes this difficult, but not impossible.

But again, normal usage of FreeMarker does not involve the template code mutating domain objects, and certainly does not involve making direct SQL queries to a database. That you can expose methods that do those things (and surely some people do) is another matter, but it is not normal encouraged usage.

So, the suggestion that a popular template engine such as FreeMarker encourages model-view entanglement is based on extremely stretched argumentation that is clearly of a straw-man nature. FreeMarker is in fact carefully designed so as to <i>discourage</i> model-view entanglement. Though, I do grant that it does not render it impossible.

In any case, Frank, you state that Velocity "provides a very capable template language". (Of course, it depends on your definition of "capable", but compared to what?) Anyway, you say it provides this capable template language, but your templates became unwieldy. Is this not a contradiction?

For starters, is it not a fallacy to think that if your templates became unwieldy with template language X that you need a template language Y that is more simplistic? If a large FORTRAN or COBOL program becomes unwieldy, does this imply a need for a more simplistic programming language or a more powerful one?

My own interpretation (and I could be wrong, of course) is that your Velocity templates became gradually unmanageable because Velocity is an extremely underpowered tool that lacks key things you need in a template language.

In any case, I am quite interested in reactions to my above-cited blog entry at http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html
My honest feeling is that there are a lot of fallacies floating around about the whole template topic and it would be useful to have a serious discussion about it to clear the air.

Eelco Hoekema

Posts: 2
Nickname: eelco
Registered: Jan, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 2:23 AM
Reply to this message Reply
> How to split that neatly into "business logic" and
> "presentation logic"?

In the end, there's an interchange of data between the gathering of the data, and the template. That is an interface that you just might want to design and govern. In most cases that would be overkill, however in some cases, when working with large teams, that would help in making the right choices.

Geert Bevin

Posts: 28
Nickname: gbevin
Registered: Aug, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 2:32 AM
Reply to this message Reply
> Pushing
> the complexity into your java code is obviously not the
> solution, since that clearly does violate separation of
> concerns.

That's totally wrong. So you mean that people that do only Java development with for example Swing applications or Java Webstart apps are unable to separate concerns? It's up to you to do the separation and properly think about it. Shoving logic into a template engine isn't separating concerns, it's setting apart some logical instructions into another location. If you don't properly think about what really has to happen with your view logic and layout logic, you're bound to very quickly violate the separation of concerns with scriptlets.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 2:54 AM
Reply to this message Reply
> In any case, I am quite interested in reactions to my above-cited blog entry at http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html

Agreed, the world is gray, and different development styles work for different teams. :)

As for the separation of roles between designers and programmers though, imho there is little evidence that this really is conventional wisdom. Unfortunately quite the opposite if you ask me, as there are not a lot of frameworks that actually enforce this separation, and as the typical thing I hear/ read in discussions (including your article) is that people say that it is *theoretically* a nice idea, but not very practical.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 3:04 AM
Reply to this message Reply
> > Pushing
> > the complexity into your java code is obviously not the
> > solution, since that clearly does violate separation of
> > concerns.
>
> That's totally wrong. So you mean that people that do only
> Java development with for example Swing applications or
> Java Webstart apps are unable to separate concerns? It's
> up to you to do the separation and properly think about
> it. Shoving logic into a template engine isn't separating
> concerns, it's setting apart some logical instructions
> into another location. If you don't properly think about
> what really has to happen with your view logic and layout
> logic, you're bound to very quickly violate the separation
> of concerns with scriptlets.

I'm with Geert here.

It's just how you define seperation of concerns when it comes to the UI I guess. Mine would be seperation between presentation and logic (or the dynamic aspects). The presentation is your static blue print, and the logic is the runtime behavior that works on it. Both can be expressed in languages that suit them best (like HTML for presentation and Java or Ruby or whetever for logic).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

The absence of templates Posted: Jul 24, 2007 4:55 AM
Reply to this message Reply
This topic has been done before. I like the DOM builder approach used in Seaside. If you give it a little thought - you are really trying to transmit a serialized hierarchical object model to a browser. You have to serialize parts of your data model anyhow, so why not just use a builder style api to specify the whole structure instead of specifying part of it as markup and part of it as code that builds part of it?

Another variant of this discussion is here:
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3257728961

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 11:08 AM
Reply to this message Reply
> > Pushing
> > the complexity into your java code is obviously not the
> > solution, since that clearly does violate separation of
> > concerns.
>
> That's totally wrong.

<sigh>

Geert, I'm satisfied that you didn't really understand the basic argument I was making. You should try harder.

> So you mean that people that do only
> Java development with for example Swing applications or
> Java Webstart apps are unable to separate concerns?

No, that is not what I meant, Geert. I was not saying anything about Java development with Swing applications. I thought that was obvious.

I'll try again:

What I was saying is that just taking presentation issues on their own the view layer may be quite complex programmatically. This complexity must be dealt with somewhere. If putting business logic in the template is a sort of entanglement, then putting logic that solely pertains to the presentation layer in your java code is also a sort of entanglement. That is why my thinking on this had led me to believe that extremely simplistic template engines are not the solution to the problem.

In any case, as I said, to believe that you end up with simpler templates by having a simpler template language is a first-order logical fallacy. You can actually show the fallacy in reductio ad absurdum fashion via the following: What is the simplest computer language possible? Well, probably the native machine language of a RISC (reduced instruction set chip) processor. This being the simplest computer language possible, programs written directly in that language should be the simplest ones, right? NOT! (Obviously.)

We want simple templates. How are we going to have that? By having as simple a template language as possible, right? Again, NOT!

Okay, let's think about this a bit more. What does a template do in principle? On the basis of a range of possible canonical data from the business logic layer, it generates a page (hopefully aesthetically pleasing) for the human end user to read and possibly interact with. The human could be in a range of locales with different currencies and number formats. The person could be vision impaired and need special output with large fonts and high contrast. The page may need certain layers of customization because this is an affiliate marketed service. There is frequently going to be the need for programmatic logic to display the data under all circumstances.

> It's
> up to you to do the separation and properly think about
> it. Shoving logic into a template engine isn't separating
> concerns, it's setting apart some logical instructions
> into another location. If you don't properly think about
> what really has to happen with your view logic and layout
> logic, you're bound to very quickly violate the separation
> of concerns with scriptlets.

I can't quite parse what you're saying above. It is chock full of muddled thinking.

First sentence: Yes, it's up to you to do it because it's your project and so on... but that's vacuous...

Second sentence on "shoving logic": The question is whether the logic in question naturally pertains to the presentation layer or not. Now, the presentational logic can be structured better or worse, with reuse and encapsulation of repeated elements, but again, as long as the logic in the template pertains to presentation issues, by my sense of what these terms mean, you are not violating separation of concerns by dealing with it in the template layer. Quite the opposite.

Final sentence above: When you use java scriptlets in JSP to solve a purely presentational issue, yes, you are violating separation of concerns, because the page is no longer maintainable by the kinds of people you want to be able to maintain it, at least without significant help from java programmers. That is the situation you want to avoid. So we agree on that. But again, the reason the situation would arise is not because of the use of a powerful template language, but because you are using a template engine that is insufficiently powerful.

Now, finally, I cannot resist adding a final point here. We are not acquainted. I am one of the main freemarker developers, the main author of the engine's core. Well, you probably know that. But the thing is, and I don't know how this comes off to you, as egotistical or whatever, but I have had cause to think about these issues quite a bit. I am not Einstein, but I am reasonably on the ball by most standards. It is quite unwise to dismiss my observations on this topic out of hand. It really is....

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 11:27 AM
Reply to this message Reply
> > > Pushing
> > > the complexity into your java code is obviously not
> the
> > > solution, since that clearly does violate separation
> of
> > > concerns.
> >
> > That's totally wrong. So you mean that people that do
> only
> > Java development with for example Swing applications or
> > Java Webstart apps are unable to separate concerns?
> It's
> > up to you to do the separation and properly think about
> > it. Shoving logic into a template engine isn't
> separating
> > concerns, it's setting apart some logical instructions
> > into another location. If you don't properly think
> about
> > what really has to happen with your view logic and
> layout
> > logic, you're bound to very quickly violate the
> separation
> > of concerns with scriptlets.
>
> I'm with Geert here.

Yeah, I think you are. In my response, I made no bones about the fact that I didn't think Geert understood my point. And, yes, you're with him on that. :-)

>
> It's just how you define seperation of concerns when it
> comes to the UI I guess.

Eelco, this is not really something that open to multiple definitions or interpretations. You can differ with me, fine, but I say that "separation of concerns" is a very concrete problem; it's that you want the presentation to be maintainable by people who are not java programmers. That is clearly the goal of the templating system.

Once you push logic that pertains solely to presentation into the java layer, you are not achieving that goal any more. That aspect of the presentation cannot be altered by front-end people without getting java programmers involved. So I do not see any sensible definition of "separation of concerns" whereby you put presentational logic in java code.


> Mine would be seperation between
> presentation and logic (or the dynamic aspects).

Well, the above is not a correct dichotomy. In the general case, presentation of data does (at least potentially) involve programmatic logic.

> The
> presentation is your static blue print, and the logic is
> the runtime behavior that works on it. Both can be
> expressed in languages that suit them best (like HTML for
> presentation and Java or Ruby or whetever for logic).

Look, let's take a concrete example. You develop a website in the United States. One piece of data it tells you is the closest place to the user's location that he can buy an acme widget. It says: the nearest reseller is at 500 Normal Road, which is 5 miles from your location.

You take the product to Europe. There is at least one thing that has to happen in the above output. The distance must be displayed in kilometers.

This is a purely presentational issue really. 5 miles is the same thing as 8 kilometers. The person in Europe needs to see the latter and the person in the U.S.A. wants the former. To say that changing a presentational element of this nature requires java programming is, in my universe, to violate separation of concerns.

To believe, in the general case, that in your typical ecommerce website, that you can take all the logic out of the presentation side is, AFAICS, a misguided idea, and like any dogma taken to extremes, will not lead to very good results.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 11:57 AM
Reply to this message Reply
> > In any case, I am quite interested in reactions to my
> above-cited blog entry at
> http://freemarker.blogspot.com/2006/07/designerdeveloper-di
> vision-of-labor.html
>
> Agreed, the world is gray, and different development
> styles work for different teams. :)

That isn't what the above-linked article was saying. Did you actually read it?

>
> As for the separation of roles between designers and
> programmers though, imho there is little evidence that
> this really is conventional wisdom.

Well, it depends on which circles you're talking about. I mean, hundreds of millions of people surely believe that the earth is flat. Maybe in Subsaharan Africa or in the Amazonian jungle, most people believe that. OTOH, most of those people would be totally uneducated, illiterate. Among even minimally educated people, such a belief would be quite rare.

Obviously there are lots of hackers out there who put together whatever it is and are happy when it basically works. I mean, take the example of the JSP defender who posted his horrendous JSP snippet and asks, well, what's wrong with that? I'm not talking about that, I mean, there are people who are more thoughtful about what they are doing and try to follow best practices. Among those people, I would say that the 2-way separation of roles is a conventional wisdom by now. It's generally recognized that putting java scriptlets in your JSP's is not good practice and so on. In JSP Model 2, I think scriptlets are basically deprecated. And the reason for that, presumably, is the separation of concerns.

Okay, if you're stuck in some time warp where it's still 2000 and Velocity is a "very capable template language" and typical usage of JSP is with java scriptlets and so on, sure. But even if progress is at a glacial pace (for whatever reasons) progress does occur. We really ought to be at the stage of history where people recognize certain basic things.

> Unfortunately quite
> the opposite if you ask me, as there are not a lot of
> frameworks that actually enforce this separation, and as
> the typical thing I hear/ read in discussions (including
> your article) is that people say that it is
> *theoretically* a nice idea, but not very practical.

Well, yes, my article is saying that the 2-way separation of concerns is incomplete because the presentation layer naturally contains significant amounts of programmatic logic and, in a 2-way separation paradigm, it is not really that clear who is maintaining that. OTOH, the article is not arguing against a separation of concerns, just saying that, in the general case, you need to think more in terms of a 3-way separation, which is a different sort of argument.

But, in any case, if people are telling you that the approach you are espousing is not practical, Eelco, well... one possibility to consider... is... that they're right! If you're saying (as you seem to be saying above) that separation of concerns means that a template does not contain any logic at all -- even that which pertains solely to presentation itself -- then obviously you're not espousing anything very pragmatic. So, it's normal that people react to that by saying it's not practical.

So this leads to the question: Do they say that a given approach is not practical because they don't understand what separation of concerns is about or is it, in fact, that your understanding of the issue is defective? Quite frankly, I suspect the latter...

Geert Bevin

Posts: 28
Nickname: gbevin
Registered: Aug, 2006

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 12:11 PM
Reply to this message Reply
> Now, finally, I cannot resist adding a final point here.
> We are not acquainted. I am one of the main freemarker
> developers, the main author of the engine's core. Well,
> you probably know that.

Actually, no, I didn't know that and I honestly don't care that much who you are after glancing over the posts you just added. You managed to say to several people that they're somehow too stupid to understand your magnificent reasoning ... way to go!

> But the thing is, and I don't know
> how this comes off to you, as egotistical or whatever, but
> I have had cause to think about these issues quite a bit.
> I am not Einstein, but I am reasonably on the ball by most
> standards. It is quite unwise to dismiss my observations
> on this topic out of hand. It really is....

Given the sheer amount of arrogance you demonstrate in your posts here, I'll have to scrape together the courage to respond to the topic at hand. I don't really have the time to invest at the moment, but later today or tomorrow I'll try to respond intelligibly to the points of Mr. Jonathan, The Über Template Engine Expert ... bleergh.

Jay Sachs

Posts: 30
Nickname: jaysachs
Registered: Jul, 2005

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 1:24 PM
Reply to this message Reply
> What I was saying is that just taking presentation
> issues on their own
the view layer may be quite
> complex programmatically. This complexity must be dealt
> with somewhere.

I completely agree ...

> If putting business logic in the
> template is a sort of entanglement, then putting logic
> that solely pertains to the presentation layer in your
> java code is also a sort of entanglement.

... but what exactly do you mean by "java code"? If you mean "the wrong layer in your java code", I agree. However, I see no reason a priori not to use Java to express the potentially complex presentation logic.

> Okay, let's think about this a bit more. What does a
> template do in principle? On the basis of a range of
> possible canonical data from the business logic layer, it
> generates a page (hopefully aesthetically pleasing) for
> the human end user to read and possibly interact with.

I've seen this conflation a lot in this thread. Maybe it's my inappropriate generalizing, but I take "template" to mean something that generates text-based content. Not just HTML.

> > It's
> > up to you to do the separation and properly think about
> > it. Shoving logic into a template engine isn't
> separating
> > concerns, it's setting apart some logical instructions
> > into another location. If you don't properly think
> about
> > what really has to happen with your view logic and
> layout
> > logic, you're bound to very quickly violate the
> separation
> > of concerns with scriptlets.
>
> I can't quite parse what you're saying above. It is chock
> full of muddled thinking.

I'll second Jonathan's inability to parse. Geert, can you elaborate on the qualitative differences between "presentation logic" and "other logic"? It seems that you have a preconceived notion about what things ought to be presentable, and how that presentation must execute. Perhaps there's a fundamental disagreement that presentation logic can be complex enough to warrant a Turing-complete tool. I've definitely run across situations where I want/need such power.

> Now, finally, I cannot resist adding a final point here.
> We are not acquainted. I am one of the main freemarker
> developers, the main author of the engine's core. Well,
> you probably know that. But the thing is, and I don't know
> how this comes off to you, as egotistical or whatever, but
> I have had cause to think about these issues quite a bit.
> I am not Einstein, but I am reasonably on the ball by most
> standards. It is quite unwise to dismiss my observations
> on this topic out of hand. It really is....

Jonathan, I tend agree with most of your technical points. But here you're really coming across as condescending and patronizing. If you state your background as a "full disclosure", that's one thing. But here you seem to be trying to use it as part of your argument ("my points are valid because I say I've thought a lot about it, and by implication you haven't thought about it") and all your arguments get lost.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine? Posted: Jul 24, 2007 1:35 PM
Reply to this message Reply
> > Now, finally, I cannot resist adding a final point
> here.
> > We are not acquainted. I am one of the main freemarker
> > developers, the main author of the engine's core. Well,
> > you probably know that.
>
> Actually, no,

<sigh>

Well, okay, I guess this does explain something or other. After all, I pointed to the blog entry I wrote on this topic and the blog in question is freemarker.blogspot.com, "the official weblog of the freemarker project." Who typically writes on the XXX blog, Geert? The developers of XXX maybe?

When I say that you probably know that I'm a freemarker developer, I am basically giving you credit (mistakenly, apparently) for being just a little bit on the ball. Thank you for correcting me on that.

> I didn't know that and I honestly don't care
> that much who you are after glancing over the posts you
> just added.

Okay, you're one of these guys. You affect that you welcome a debate on some topic to which you have devoted a lot of thought, but then actually shrink from such a debate.

But the real point is, don't you realize that you just discredit yourself by this kind of pussy behavior? Anybody who was not born yesterday can see that you do not respond to me with legitimating debating points because you cannot. So you opt for this kind of approach of affecting to be so offended by me.

However, in terms of disrespecting other people, you clearly started it. You claimed in a blanket, rather inflammatory, way that what I was saying was completely wrong and then brought in this irrelevant nonsense about programming Swing apps.

> You managed to say to several people that
> they're somehow too stupid to understand your magnificent
> reasoning ... way to go!

No, I did not say that, Geert. I do not know whether they are too stupid to understand my points. I simply stated, on the basis of their discourse, that they had not understood what I said. Do not put words in my mouth.

If I said (I don't know whether I said it, but I'll say it now) that you or Eelco do not really understand the separation of roles concept, it is because I honestly believe that you don't.

Anyway, that you don't realize that a guy who writes on the official freemarker blog is a freemarker developer is a sign of a certain level of brain death -- or part of your brain may be asleep.

>
> > But the thing is, and I don't know
> > how this comes off to you, as egotistical or whatever,
> but
> > I have had cause to think about these issues quite a
> bit.
> > I am not Einstein, but I am reasonably on the ball by
> most
> > standards. It is quite unwise to dismiss my
> observations
> > on this topic out of hand. It really is....
>
> Given the sheer amount of arrogance you demonstrate in
> your posts here, I'll have to scrape together the courage
> to respond to the topic at hand. I don't really have the
> time to invest at the moment, but later today or tomorrow
> I'll try to respond intelligibly to the points of Mr.
> Jonathan, The Über Template Engine Expert ... bleergh.

I think you should at least try, Geert, because to engage in personal insults in a debate because you are not capable of responding to the other person's debating points is quite unseemly. It speaks poorly of your character and it will only serve to discredit you and your work.

Flat View: This topic has 69 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: What Do You Look For in a Template Engine? Previous Topic   Next Topic Topic: Python 3000 Sprint @ Google


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us