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