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

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

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

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 69 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: The absence of templates

Posted: Jul 24, 2007 10:47 AM

> 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?

If you look at it strictly as a programming problem, there is something to say for that yes.

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

I've read that before as well, but don't agree with the conclusion. I prefer to view the UI of web applications as static blocks (templates/ HTML files) where only some sections are dynamic, and those section often stay relatively close to their blueprints. For instance, a list with Wicket could look like this:
template:


<p wicket:id="comments">
  <span wicket:id="date">1/1/2004</span><br>
  <span wicket:id="text">Comment text goes here.</span>
</p>

Java:


add(new PropertyListView("comments", commentList) {
  public void populateItem(final ListItem listItem) {
    listItem.add(new Label("date"));
    listItem.add(new MultiLineLabel("text"));
  }
});

The Java part could indeed have been in charge of rendering a <p> for each row. But say, you don't want a paragraph section but instead an unnumbered list:
template:


<ul>
  <li wicket:id="comments">
    <span wicket:id="date">1/1/2004</span><br>
    <span wicket:id="text">Comment text goes here.</span>
  </li>
</ul>

I think it makes sense to be able to change this (or let your web designer do this) without having to go back to the code. This template might be a direct copy of the design documents, and is previewable without Java.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 11:04 AM

> > 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"?

What exactly could I mean? I mean code written in the Java language as espoused by Sun Microsystems.

The scenario I am considering is that you have a programmatic problem that clearly is just presentation oriented. You want to encapsulate some repeated display element, like displaying a list of tournament results in a complex table or something. If you're using a template tool that is not sufficiently powerful to encapsulate (parametrically) this display, the temptation could exist to put the logic in 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.

My sense of things, and what has guided my work on freemarker, has been the idea that you would like your presentation layer to be maintainable by people who are not hard-core programmers. Once you put presentation logic in java code, you are basically accepting that such people cannot maintain it without the active collaboration of the java programmers.

As I understand it, this is precisely the entanglement that one should want to avoid and this, to me, is what we're talking about when we talk about separation of concerns.

>
> > 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.

Yeah, that's true in general. For example, FreeMarker is. used by various people (like in Hibernate) to generate java source code. And I know of other people who use it to generate other stuff, like XML, that is then read by some other automated process....

However, this conversation, I think, is basically about templating in the web application space, so I was talking about that. Also, I think that, at least in the case of freemarker usage (but surely jamon and stringtemplate and others) the web application space is dominant in practice.

I thought that was all pretty clear. Basically, I (and others) are taking this templating conversation to be about templating in the web space.

>
> > > 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.

I think most people do. The other odd thing about this is that the view layer, as a whole, is moving towards having more programmatic logic in it anyway -- I mean, the extended use of Javascript in DHTML and so on. Just stuff like what happens when you hover your mouse over this region and so on... that's logic, it's programming... isn't it???

That's not on the templating layer, I grant, but I mean, this whole austere doctrine that you have no programmatic logic in the view layer is really rather odd finally...

>
> > 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.

Mea culpa. You're probably right. I am not known for being that diplomatic.

All that said, I do basically stand by what I say there, even if I recognize that somebody else could maybe point it out more diplomatically. You can certainly disagree with anything I say, but you should feel an onus to carefully lay out your argument. What Geert did was simply dismiss out of hand what I was saying with the most flimsy (and really, fallacious) arguments possible.

To tell him who I am and that I have had cause to think deeply about these issues is, I think, on some level, right and proper.

Anyway, I have a hard time being diplomatic about it. I have a strong sense that this business of "We want simple templates, so we need a dead simple template tool" is based on a first-order fallacy and if these guys could just realize that, they'd save a lot of their own time, and better apply their energies. And when I say that, it's bound to come off as condescending, but... what to do? It really is what I honestly think. To hide what I think doesn't IMO do much service to people, because it encourages them to go down this "dumbed down template engine" route that I consider to be a dead end.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 11:40 AM

> I made no bones about the fact that I didn't think Geert understood my point.

If you want people to understand you, a friendlier approach might help and I'm sure it would help if your posts were shorter/ more too-the-point.

>> 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.

How is it not?

> 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.

Yes. And if you change objects and services in your business layer you'll have the same problem.

Also 'logic that pertains solely to presentation' presumes a strict seperation of logic for presentation and other (business layer?) logic. But I think that in real life this distinction usually isn't as obvious. For instance, say you implemented the displaying of a list of users as just a plain list. Later on, you decide to build in filtering and paging. You'll have to get back to your Java (or whatever language) layer for that. And this is just a simple example really.

The end of the day, the people working on the separate layers will have to work together. There are a zillion different ways of organizing this. My preferred way is to start with designs/ templates and then start filling in the dynamic parts. In my experience, once the designs are stable we don't often have to make drastic changes.

> So I do not see any sensible definition of "separation of concerns" whereby you put presentational logic in java code.

Seperation of concerns in my book does not equal 'seperation of teams' (though it might help with that).

> 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.

That's a funny example indeed. I don't see any reason for this kind of logic to be in my templates. I think something like this:

add(new Label("distance", new DistanceModel(dist)));

where DistanceModel encapsulates the logic to provide the correct representation of the distance according to the user's locale makes a lot more sense. The template portion could look like this:


<wicket:message key="distance">Distance: </wicket:message><span wicket:id="distance">100 KM</span>

> 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.

Interestingly, you present your rejection in quite a dogmatic way. While dogmas are evil, strong principles aren't. A seemingly 'pragmatic' approach in programming sometimes hurts more than it does good, especially when it comes to API design and issues like we are discussing here.

As for your statement that a strict seperation of presentation and logic does not lead to good results... I wonder where you base that on. Intuition maybe? I have been working like this for the last trhee years, and it works great for me. And as I've heard/ read from quite a few people stating this seperation works well for them, I believe that this is at the very least a viable approach.

Jay Sachs

Posts: 30
Nickname: jaysachs
Registered: Jul, 2005

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 11:51 AM

> My sense of things, and what has guided my work on
> freemarker, has been the idea that you would like your
> presentation layer to be maintainable by people who are
> not hard-core programmers. Once you put presentation logic
> in java code, you are basically accepting that such people
> cannot maintain it without the active collaboration of the
> java programmers.

Jonathan, you seem to be pursuing conflicting goals, or at least goals in mutual tension. If the presentation logic is complicated enough to exceed Velocity's capabilities, and perhaps requires recursion etc, then I'd say that regardless of the technology, that part of it, at least, is beyond the capability of non-hard-code programmers. Just because it's not Java doesn't make it amenable for a non-developer to work with.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 12:00 PM

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

Well, I tried to. But it's sheer size and lack of focus made it difficult to get your point. So yes, I probably missed it.

> 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.

Did you read *my* reply? Here it is again:

"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."

We seem to have a difference of opinion in what we label "designers". Your's seem to be programmers in disguise. Also, your objections against seperating logic from presentation so far have been purely 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...

Maybe you should have been clearer in what kind of reactions you were expecting when you asked people to read your blog entry. Maybe something in the lines of 'I am quite interested in hearing that people agree with above-cited blog entry...'.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The absence of templates

Posted: Jul 24, 2007 1:50 PM

> I think it makes sense to be able to change this (or let
> your web designer do this) without having to go back to
> the code. This template might be a direct copy of the
> design documents, and is previewable without Java.

Templates are code. They have mixed syntax, but they are code. I've had better luck doing simple html and letting the designers do their thing with CSS. Designers shouldn't be doing html at all.

CSS is separate - even lives in a different file. You only need to provide appropriate addressing conventions for the CSS designer to do his thing.

I have tried all approaches - JSP-ish, WebObjects/Tapestry (and apparently wicket - with which I am not familiar - but the approach seems to be the same), and Seaside's builder. I prefer the builder - althought I can see how that approach might be somewhat inconvenient without closures.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: The absence of templates

Posted: Jul 24, 2007 2:05 PM

> Templates are code. They have mixed syntax, but they are
> code. I've had better luck doing simple html and letting
> the designers do their thing with CSS. Designers
> shouldn't be doing html at all.

There is certainly something to say for that.

> CSS is separate - even lives in a different file. You
> only need to provide appropriate addressing conventions
> for the CSS designer to do his thing.

The way I like to work is to go from designs/ mockup to implementation, and keep the mockups almost unchanged. Without templates, I wouldn't have the option of working like this. But fair enough, I think a code only approach can work well too.

> I have tried all approaches - JSP-ish, WebObjects/Tapestry
> (and apparently wicket - with which I am not familiar -
> but the approach seems to be the same)

Wicket is different from the two frameworks (or at least Tapestry as I'm not too familiar with WO) in quite a few aspects, including the fact that Wicket doesn't allow to embed logic in templates, whereas at least Tapestry does.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 2:25 PM

> > That isn't what the above-linked article was saying. Did
> you actually read it?
>
> Well, I tried to.

<sigh>

So.... in other words, you did not actually read it. (You tried to??? WTF kind of mealy-mouthed nonsense is that? It's not that long.)

> But it's sheer size and lack of focus
> made it difficult to get your point.

Well, in particular, if you did not, in fact, read the article in the first place, that would make it difficult to get my point, yes.

> So yes, I probably
> missed it.

Then why did you represent that you had read it and understood it?

I think that's what you did. I think anybody would have inferred from your earlier post that you had read the article and understood its main points. Now it seems you're saying that you didn't.

You know, I had originally felt that maybe I was being too abrasive and so on. (And maybe I was...) You know, and I felt that Jay Sachs, who seems to be a reasonable guy, was taking me to task with some justification.

However, finally, I throw up my hands. When I suggested, on the basis of your response (since it had nothing to do with what I was saying in the article) that you had not read or understood my article, it now appears that my inference was correct. You didn't read it, but I'm the bad guy for simply pointing out the obvious -- basically, for short-circuiting the phony, lazy, posturing you were engaging in.

If you didn't read the article, you shouldn't be posturing that you have done so. Period. And then when you get caught BS'ing, to turn it around on me, saying that the issue is my deplorable personality. Sorry, it doesn't wash.

<snip>

> Did you read *my* reply? Here it is again:
>
> "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."
>
> We seem to have a difference of opinion in what we label
> "designers". Your's seem to be programmers in disguise.

In the article that it now appears you didn't read, which is here:

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

I actually address this issue. The point is that I argue that the 2-way separation of roles, that paradigm, is insufficient, and you need to think in terms of a third role, which I call "website integrator". And, yes, the website integrator is not a graphical designer and not a hard-core programmer. It's a third role.

> Also, your objections against seperating logic from
> presentation so far have been purely practical.

????!!!!

Well.... as Steve Martin used to say... Excuuuuse meeeee. :-)

>
> > 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...
>
> Maybe you should have been clearer in what kind of
> reactions you were expecting when you asked people to read
> your blog entry.

Eelco, there is at least one of us who has not totally lost the ability to reason logically. if I knew what people's reactions would be before they read it, I wouldn't need to ask for their reactions.

However, one thing that I took for a given was that when somebody gave me his reaction to it, that he had actually read it. Is that such an unreasonable assumption?

>Maybe something in the lines of 'I am
> quite interested in hearing that people agree with
> above-cited blog entry...'.

You just tacitly admitted that you didn't read it in the first place.

If you read it and disagreed, by all means, explain why, on what grounds. But this clownish behavior of posturing that you read something and then having to admit that you didn't read it.... Sheesh.... why are you behaving like this in a public forum? For crying out loud, get up from your computer, take a walk, take a deep breath, think about what you're doing.... Really....

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 3:01 PM

> > I made no bones about the fact that I didn't think Geert
> understood my point.
>
> If you want people to understand you, a friendlier
> approach might help and I'm sure it would help if your
> posts were shorter/ more too-the-point.

Look, it is perfectly possible that the article I referenced could be edited down somewhat, sure. However, in what way does this justify somebody pretending that he read something when he didn't?

In any case, it is a 2200 word essay. Supposedly you're interested in this space, but are not interested enough to read a 2200 word essay by a guy who is the main developer of one of the primary templating tools.

That's fine, I don't care, but don't represent that you read stuff when you didn't. I find that behavior to be quite obnoxious. It is silly to then whine that I behave in an "unfriendly" way subsequent to 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.
>
> How is it not?

I believe I explained why. Once you push display logic into the java code, the people who you want to take ownership of these presentation details cannot do so. You've created a first order impedance.

>
> > 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.
>
> Yes. And if you change objects and services in your
> business layer you'll have the same problem.

No, not necessarily. Not if you expose the same data structures to the template that you did before. Then the templates will simply continue to work. Of course, sometimes that's not possible, and you need to change the contract of what data is available from the template, and then you need to communicate it to the people who work on that layer.

>
> Also 'logic that pertains solely to presentation' presumes
> a strict seperation of logic for presentation and other
> (business layer?) logic. But I think that in real life
> this distinction usually isn't as obvious. For instance,
> say you implemented the displaying of a list of users as
> just a plain list. Later on, you decide to build in
> filtering and paging. You'll have to get back to your Java
> (or whatever language) layer for that. And this is just a
> simple example really.

Well.... whatever... but this pertains to a kind of all-or-none fallacy. A smoker will tell me that there is no point in his stopping smoking because he could still get cancer even if he stops smoking. True, but by smoking, he's making it a lot more probable.

Even if, in the real world, the front-end coders will sometimes need to ask for help from the java guys, it is desirable to make this less frequent, so that, to a maximal extent possible, the two groups can work independently.

>
> The end of the day, the people working on the separate
> layers will have to work together.

Yes, and both the smoker and non-smoker will eventually die. It is stil a key point that the smoker will, on average, die sooner.

Similarly, with a well architected system, the need for the designers to come running to the programmers to get whatever done will be less, and there will be greater productivity overall.

What you say above reeks of all-or-none fallacy.

> There are a zillion
> different ways of organizing this. My preferred way is to
> start with designs/ templates and then start filling in
> the dynamic parts. In my experience, once the designs are
> stable we don't often have to make drastic changes.

Not often? That means that sometimes you do, right?

>
> > So I do not see any sensible definition of "separation
> of concerns" whereby you put presentational logic in java
> code.
>
> Seperation of concerns in my book does not equal
> 'seperation of teams' (though it might help with that).

I said in the article that you pretended to have read that it doesn't necessarily mean you have separate teams. I said that the 3-way paradigm I was suggesting could be useful even for a one-man team because it could provide a conceptual model to partition the problem space.

>
> > 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.
>
> That's a funny example indeed.

You mean ha-ha funny or weird funny?

> I don't see any reason for
> this kind of logic to be in my templates. I think
> something like this:
>

> add(new Label("distance", new DistanceModel(dist)));
>

Mark Twain famously quipped that it's easy to make money in the stock market. You buy a stock and then when it goes up a bunch, you sell it. And if it doesn't go up, don't buy it.

In the above, you are assuming that you know in advance all the different ways that a front-end person might want to display your data. In this exact case, you have anticipated that they will want to display kilometers and well as miles.

However, I was specifically considering a case where the service was moved to Europe and the need to display kilometers had not been considered in advance. Does this strike you as unrealistic?

In any case, this is just one possible example. Is it realistic to think that the java programmers will know in advance all the different ways that somebody might want to display the data?

Maybe it would be better to just let the front-end person deal with this. So, that in the template where they have:

The distance is ${distance} miles.

they replace that with.

The distance is ${distance*1.6} kilometers.

without any programmer intervention. Do you or anybody else who works with back end systems want front end people bugging you every time they want to make some minor change to how they display data?

Silly dogmas aside, wouldn't it be better to just let them do what I show in the latter snippet? In what way does this really violate the model-view separation of concerns?

>
> where DistanceModel encapsulates the logic to provide the
> correct representation of the distance according to the
> user's locale makes a lot more sense. The template portion
> could look like this:
>
>


> <wicket:message key="distance">Distance:
> </wicket:message><span wicket:id="distance">100 KM</span>
>

You are assuming that the need for displaying in separate units is anticipated by the programmers. It might not be. Just as it's impossible to follow Mark Twain's (joking) investment advice, because you don't know for sure whether the stock is going up or not, your advice on this cannot be followed in the general case, because it is impossible to anticipate all the different ways in which you might want to display data in the view.

>
> > 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.
>
> Interestingly, you present your rejection in quite a
> dogmatic way.

Oh, so my statement that dogmatism is bad is itself dogmatic. Similarly, the atheist's firm belief that there is no God is in fact a religious belief, I guess.

Okay, fine.... but that's all just silly hair-splitting anyway, isn't it?

> While dogmas are evil, strong principles
> aren't.

Well.... only if the principles are correct,.... OTOH, I am arguing that the "strong principles" you believe in are the conseqence of fallacious, muddled thinking. If I am right about that, the strong principles in question are unlikely to be beneficial, and I think would be characterized appropriately as "dogma".

> A seemingly 'pragmatic' approach in programming
> sometimes hurts more than it does good, especially when it
> comes to API design and issues like we are discussing
> here.
>
> As for your statement that a strict seperation of
> presentation and logic does not lead to good results...

I actually do not argue that. I argue that presentation, in the general case, inherently contains logic, so that what you are saying is essentially nonsense.

>I
> wonder where you base that on. Intuition maybe? I have
> been working like this for the last trhee years, and it
> works great for me. And as I've heard/ read from quite a
> few people stating this seperation works well for them, I
> believe that this is at the very least a viable approach.

That people manage to be successful with whatever approach, that something "works" is not really a very strong argument. Earlier, (amazingly) you take me to task saying that my objections to whatever are all purely practical, as if that was a weak agument or something. That whatever approach basically "works" is an exceedingly weak argument, since that begs the question at hand, which is whether the approach is optimal or not.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 3:09 PM

> > > That isn't what the above-linked article was saying.
> Did
> > you actually read it?
> >
> > Well, I tried to.
>
> <sigh>
>
> So.... in other words, you did not actually read it. (You
> tried to??? WTF kind of mealy-mouthed nonsense is that?

My god how difficult is this to *get* this tiny little piece of sarcasm?! With: "I tried to", I actually meant, yes, I've read the whole post, and I thought it was lenghty, and I didn't see the point you were trying to make in relation to this thread.

> If you read it and disagreed, by all means, explain why, on what grounds.

If I would have felt the urge of discussing your article directly, I would have done so on your blog.

Anyway, since you ask for it, I wasn't thrilled by your article. So in real life, having a strict seperation of the programmer and designer roles doesn't always work, and it makes sense to think of a role of 'website integrator'. Yawn. Was there actually anything new you were trying to say?

As the world clearly isn't gray to you, my remark:

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

in the context of your blog was wrong. I guess. At least, if what you are proposing is that you should *always* have these three roles (and not two or four or WhateverWorksForYourParticularCase). And yes, I understand they don't have to be fulfilled by seperate people.

Then there was:

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

which was directly in reply to:

> The conventional wisdom floating around about template engines is that they facilitate a division of labor between two basic groups: programmers, who are concerned with business logic, and designers, people who are more concerned with the aesthetics of a website.

Does that clear my first reply up?

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 3:19 PM

> Look, it is perfectly possible that the article I
> referenced could be edited down somewhat, sure. However,
> in what way does this justify somebody pretending that he
> read something when he didn't?
>
> In any case, it is a 2200 word essay. Supposedly you're
> interested in this space, but are not interested enough to
> read a 2200 word essay by a guy who is the main developer
> of one of the primary templating tools.
>
> That's fine, I don't care, but don't represent that you
> read stuff when you didn't. I find that behavior to be
> quite obnoxious. It is silly to then whine that I behave
> in an "unfriendly" way subsequent to that.

Above, you need to repeat three times I supposedly didn't read your article. You could rewrite it to fit into one scentence and still make the same point. In the same sense, your article could have been twice (or more) as short and you would have increased the chance that mere mortals like me get your point.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 3:26 PM

> > My sense of things, and what has guided my work on
> > freemarker, has been the idea that you would like your
> > presentation layer to be maintainable by people who are
> > not hard-core programmers. Once you put presentation
> logic
> > in java code, you are basically accepting that such
> people
> > cannot maintain it without the active collaboration of
> the
> > java programmers.
>
> Jonathan, you seem to be pursuing conflicting goals, or at
> least goals in mutual tension. If the presentation logic
> is complicated enough to exceed Velocity's capabilities,
> and perhaps requires recursion etc, then I'd say that
> regardless of the technology, that part of it, at least,
> is beyond the capability of non-hard-code programmers.
> Just because it's not Java doesn't make it amenable for a
> non-developer to work with.

Well, okay, I would concede that the fact that something is not Java (i.e. it's FreeMarker template language or whatever similar thing) does not mean that it can be grokked by people who are not hard-core programmers. OTOH, it does seem inescapable that putting something in the java code itself, and making it part of the java build and so on basically does turn it into a black box that is inaccessible to the non-Java programmers. And it does seem to me that if this is logic that pertains to presentation, that that is undesirable.

And, while there are no guarantees, I admit, the idea that front-end coders could eventually (perhaps initially with some guidance from the hard-core coder types) take ownership of a bunch of FreeMarker templates, strikes me as far more promising (though no guarantees...) than thinking that they can do anything with java code. Actually, I would tend to characterize putting large amounts of presentation-level logic in java code as basically giving up on the separation of concerns.

But anyway, getting back to your objection that programmatically complex things, even if not in Java, but in a fairly powerful template language, may still be inaccessible to front-end types, I grant that, and I have grappled with that question. This was what was behind the conclusion I came to that the 2-way division of roles was, at least in the general case, insufficient to describe the web application development process. And that is what the essay I linked at various times in the discussion was arguing. That is here.

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

So, basically, I'm arguing that, in the general case, you have the emergence of a third kind of role, which I call website integrator, which sort of pulls everything together. Without that, frankly it's hard to come up with a story about the division of labor that.... quite rings true..., if you see what I mean.

And again, I don't mean to imply that you necessarily have 3 or more different people to play the different roles. It may still be useful to partition the task conceptually into roughly 3 parts, so that you can make sense of what you're doing.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 3:30 PM

> > >> 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.
> >
> > How is it not?
>
> I believe I explained why. Once you push display logic
> into the java code, the people who you want to take
> ownership of these presentation details cannot do so.
> You've created a first order impedance.

Seperation of concerns according to the first Google hit on it (Wikipedea): "In computer science, separation of concerns (SoC) is the process of breaking a program into distinct features that overlap in functionality as little as possible."

I think that is a decent definition don't you? But that's pretty generic. So the next step is to translate what seperation of concerns means for your situation. One possible way of applying seperation of concerns is to make a distinction between presentation (1) and logic (2). But you can interpret seperation of concerns in multiple ways *which was exactly my point*.

> Well.... whatever... but this pertains to a kind of all-or-none fallacy. A smoker will tell me that there is no point in his stopping smoking because he could still get cancer even if he stops smoking. True, but by smoking, he's making it a lot more probable.

Look, if we're getting into this kind of non-discussions, I'm really not interesting in continuing. Spent quite too much time on it already, thank you.

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 4:05 PM

> > > > That isn't what the above-linked article was
> saying.
> > Did
> > > you actually read it?
> > >
> > > Well, I tried to.
> >
> > <sigh>
> >
> > So.... in other words, you did not actually read it.
> (You
> > tried to??? WTF kind of mealy-mouthed nonsense is that?
>
> My god how difficult is this to *get* this tiny little
> piece of sarcasm?!

I don't know if it was only me that the sarcasm was lost on. I took it to mean that you started to read it... maybe... and then never got to the end.

> With: "I tried to", I actually meant,
> yes, I've read the whole post,

I cannot easily imagine myself saying "I tried to read X" with the intent of conveying the idea that I had actually read it.

> and I thought it was
> lenghty, and I didn't see the point you were trying to
> make in relation to this thread.

Well, that's a very strange way to communicate the above idea. Maybe next time, you'd be better off saying something like:

"I read through it and didn't quite understand what point you were making as regards this conversation. Could you clarify that?"

But look, I'm not going to get into any false pretenses. I do not believe that, at the point, where you represented that you had read the thing, that you actually had read it.

For example, in a recent response, you wrote:

"We seem to have a difference of opinion in what we label "designers". Your's seem to be programmers in disguise."

In fact, if you had read the article, you would surely understand that I was proposing a third role precisely because I was assuming more programming abilities on the part of the non-java types than might be reasonable if we considered them to be pure graphical designers. That was what the "website integrator" idea was.

There is a very very strong sense throughout this conversation, and your characterizations of what I say, that you did not read the article. So, it is not just that you say "I tried to read it" which would tend to mean in most people's universe that you did not actually do so.

But let's be clear. I don't care whether you read it or not. I don't care whether you react to it or not. (I also have doubts that any feedback I would get at this point from you would be offered in good faith.)

It just really really annoys me that you represent that you read something and considered it when you didn't it.

>
> > If you read it and disagreed, by all means, explain why,
> on what grounds.
>
> If I would have felt the urge of discussing your article
> directly, I would have done so on your blog.
>
> Anyway, since you ask for it, I wasn't thrilled by your
> article. So in real life, having a strict seperation of
> the programmer and designer roles doesn't always work, and
> it makes sense to think of a role of 'website integrator'.
> Yawn. Was there actually anything new you were trying to
> say?

So, this has been said (I infer many times) before. Could you provide me the links?

>
> As the world clearly isn't gray to you, my remark:
>
> "Agreed, the world is gray, and different development
> styles work for different teams."
>
> in the context of your blog was wrong.

Well, it had nothing to do with the main point of the article.

> I guess. At least,
> if what you are proposing is that you should *always* have
> these three roles (and not two or four or
> WhateverWorksForYourParticularCase).

The article does not propose a specific methodology. It simply proposes a conceptual model for thinking about the space.

Basically, it's as if some people come at you with some simplistic marxism and say that society is made up of two groups, the capitalists (the exploiters) and the workers (the exploited) and that's how you think about it. And then I write something saying that this is overly simplistic and it's better to think in terms of, let's say... 3 groups, those two plus another one, say.

In the above, I am not proposing a different kind of social and economic organization, I am simply saying that the 2-way paradigm is not sufficient and it may be better to think in terms of 3 basic roles. The article does not propose a specific methodology actually.

> And yes, I understand
> they don't have to be fulfilled by seperate people.
>
> Then there was:
>
> "As for the separation of roles between designers and
> programmers though, imho there is little evidence that
> this really is conventional wisdom."
>
> which was directly in reply to:
>
> > The conventional wisdom floating around about template
> engines is that they facilitate a division of labor
> between two basic groups: programmers, who are concerned
> with business logic, and designers, people who are more
> concerned with the aesthetics of a website.
>
> Does that clear my first reply up?

Look, I'm convinced that you didn't read the article when you were posturing that you had, okay? When you said you tried to read it, it was like a Freudian slip, because it really meant you hadn't read it. Now, you're trying to say that there was sarcasm and "I tried to read it" definitely meant to anybody who is not brain-damaged like I am, that you actually did read it. (Really tiresome BS.)

I could be wrong, I suppose, but I have a sense of when people are BS'ing me. I think you should refrain from it. I find it offensive. For your own sake, you should try harder to maintain standards of discourse. Don't go around pretending that you read whatever it is and seriously thought about it when you darned well didn't, okay?

Jonathan Revusky

Posts: 19
Nickname: revusky
Registered: Jul, 2007

Re: What Do You Look For in a Template Engine?

Posted: Jul 24, 2007 4:31 PM

> > > >> 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.
> > >
> > > How is it not?
> >
> > I believe I explained why. Once you push display logic
> > into the java code, the people who you want to take
> > ownership of these presentation details cannot do so.
> > You've created a first order impedance.
>
> Seperation of concerns according to the first Google hit
> on it (Wikipedea): "In computer science, separation of
> concerns (SoC) is the process of breaking a program into
> distinct features that overlap in functionality as little
> as possible."

Okay, fine, but do you want SoC for its own sake, because it's just something theoretically "good" or is it for the pragmatic reason that it allows different people to work on different pieces of something and (to a maximal extent reasonable) avoid stepping on each other's toes?

And, generally speaking, shouldn't these concepts like model-view separation really be pragmatic guidelines rather than some kind of dogmatic thing to beat people over the head with?

>
> I think that is a decent definition don't you? But that's
> pretty generic. So the next step is to translate what
> seperation of concerns means for your situation. One
> possible way of applying seperation of concerns is to make
> a distinction between presentation (1) and logic (2).

No, it's not, because presentation, in the general case, requires some amount of programmatic logic. A distinction between presentation logic and business logic makes sense, but you can't have a distinction between presentation and logic generally when presentation inherently contains logical elements.

>But
> you can interpret seperation of concerns in multiple ways
> *which was exactly my point*.

Exactly your point? What is exactly your point?

>
> > Well.... whatever... but this pertains to a kind of
> all-or-none fallacy. A smoker will tell me that there is
> no point in his stopping smoking because he could still
> get cancer even if he stops smoking. True, but by smoking,
> he's making it a lot more probable.
>
> Look, if we're getting into this kind of non-discussions,
> I'm really not interesting in continuing. Spent quite too
> much time on it already, thank you.

Well, nobody is forcing you to continue to write such muddle-headed posts., full of logical fallacies. However, if you do so, I think it quite improper for you to whine when I (or anybody else) carefully deconstructs the logical fallacies you're engaging in.

Here, it's a kind of all-or-none fallacy where it doesn't matter that the front-end people have to come running to the java programmers to get whatever it is done, since there is a need for them to communicate anyway. However, surely the team is more productive if you can at least minimize the need for the people working on the web side to come talk to the java programmers when they need to do something, like display a distance or temperature in different units (which is just one example I provided, there are many more...)

Look, I can bend over backwards to be generous to your position. And here I'll try to do so:

Basically, at a certain point in time, so much of web development erred in a certain direction (exposing all kinds of inappropriate things to the template layer and causing entanglement) that there is now the tendency to err in the other direction. However, you will at some point see, I think, that emasculating the front-end coder by not allowing him to do.... well... just about anything... is also a mistake, and it does not promote "separation of concerns" -- by any reasonable definition of the term.

I am quite satisfied that, in the real world, where people solve real problems, there is a need for a powerful template engine along the lines of freemarker. This dogma, where you espouse the idea that you can remove all programmatic logic from the view (and I mean logic that inherently pertains to presentation) is just that, a dogma. It is quite revealing when you say accusingly that my arguments are all "just" practical arguments...

Flat View: This topic has 69 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic