|
Re: What Do You Look For in a Template Engine?
|
Posted: Jul 24, 2007 11:06 PM
|
|
> > What is your position on presentational logic? I see > two > > possibilities from what you have said: > > > > (a) There is no such thing, presentation and logic are > two > > separate dichotomous things. > > > > (b) Yes, there is such a thing, but since > presentational > > logic is logic, it doesn't belong on the template layer > > and should be in the java code. > > > > I see (a) and (b) as two basic logical possibilities > for > > you. In passing, it seems that the original poster, > Frank > > Sommers, does believe that there is such a thing as > > presentational logic. I infer that from the second > > sentence of the article: "Presentational logic can be > > complex enough...." > > > My position *in general* is (b) > > I believe that there are some problems/ missed > opportunities with putting logic in templates and that an > enforced separation more easily results in maintainable > code,
I have a feeling that this begs the question.
Maintainable by whom?
Do I, a java programmer, want to maintain a bunch of HTML layout defined in java code, and then be bugged by people on the business side who want the page to look a tiny bit different, and then have to put in the change and have it require a whole rebuild/recompilation/retesting of the java codebase?
Another aspect of this is that FreeMarker macros are likely to be more maintainable (and by more different people) than equivalent java methods or classes. This is not solely because java is basically a hard-core programming language. It is also because Java is quite a poor language for string handling, generating text. FreeMarker, on the other hand, is a specialized tool for string handling and output.
So, actually, I think the best guess is that freemarker macros that generate parametrizable HTML snippets will be more maintainable than equivalent components written in java.
> as it the logic will generally be more strongly > typed, easier to navigate and due to Java's tooling > support easier to debug, refactor, explore the API of > components, etc.
Here, you bring up certain valid points, I grant. There is a problem wrt to tool support for template languages -- I guess with the possible exception of JSP, and maybe XSLT, if you call that a template language, which it isn't exactly...
OTOH, the lack of tool support is remediable in principle.
As for refactoring, well, you can refactor a statically compiled language with greater confidence than a scripting/templating late binding sort of langage. OTOH, there are other counterbalancing factors there. That's a whole separate conversation really.
> > For the particular framework I'm working with, the > enforced separation of presentation and logic is really > just part of the package. We believe this separation is > helpful by itself, but it is also the enabler of some > other features which are irrelevant in the light of this > discussion.
???
> > In the end, it really depends on how you organize your > projects. If the case about localizing your site you gave > earlier may hold true for you, then a Freemarker-like > approach probably makes more sense. Also, if you read e.g. > how the programmers of Flickr organize their development > (PHP templates and a Java back-end): they strictly enforce > presentation from logic, but do it on discipline coding > both aspects in PHP. They may have the best of both > worlds, though they explictly state that it is a bad idea > to directly tweak production templates. > > > I do not recall ever providing my own personal > interpretation of what the term means. > > I thought you did when you said things like: > > '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, I say that separation of concerns mostly means, on a practical level, that different people can do their work without stepping on each other's toes. If that is my own special definition, then so be it, I will concede that this is my own special definition of the term. However, I kind of doubt it. I think that, at the end of the day, this is what SoC really does mean for most people.
I do not see how you are achieving SoC by putting all kinds of presentation-related things in java code, which is basically a black box for the kinds of people you would like to take ownership of that piece.
> > '... since that clearly does violate separation of > concerns' > > '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...' > > I though you gave me enough directions to at least > understand what you mean by it, and you also indicate that > other interpretations are wrong. > > > And, actually, come to think of it, I don't quite know > why you would react negatively to my three-way paradigm. > If partitioning the problem 2-ways is good, then > partitioning it 3 ways is arguably even better, right? > > Your three-way paradigm is fine. Whether this three way > seperation makes sense depends on how you organize your > projects/ what kind of frameworks you are using. In my > personal experience, roles overlap/ shift and aren't > always as clear. But if you develop in the way you > propose, it makes sense to have these roles defined.
My sense of things, I grant, more of an intuitive feeling, a hunch, than anything else, is that the roughly 3 roles exist in the problem space and the attempt to force things into a 2-way scheme is likely to cause more problems than it solves.
> > > The basic problem that I find in what you are saying is > the idea that having logic (even presentational logic) in > your template is a no-no, yet you see no problem w.r.t. > SoC in having such presentational logic in your java code. > It seems to me that there is clearly some disconnect > there. > > That is - as I stated before - because I believe that the > distinction is rather between the static elements of > presentation and of the dynamic parts. These two parts > together form a whole, and both make up the UI layer. The > difference between our views is that I would let Java code > modify my markup and you put the modification code in the > markup itself.
I guess that's right. I want to get all the messy HTML implementation details right the heck out of all my java code.
> > > I assume we're talking about parts that are at least > somewhat dynamic because there is no issue wrt putting > static parts of your presentation anywhere but in the > template. That's a non-issue. > > I am talking about the templates as a whole. Most > templates in my experience will have a combination of > static markup, which will typically have the purpose of > organizing (tables, list definitions, etc) and layout > (though I believe it is good practice to put most of the > actual layout code in CSS where you can),
Is there some newer CSS spec out there that I am not aware of? (I don't ask this sarcastically, honestly.) You are not the only person in this conversation saying that they would do all kinds of things in CSS. My impression has been ( at least since the last time I looked at CSS) that you can't do all that much in CSS, at least in terms of what we're talking about in this conversation...
Frankly, I find the reference to doing all kinds of stuff with CSS rather confusing... maybe there is something I'm missing here....
> and dynamic > parts, such as printing of a title, looping through a > list, conditionally displaying sections, etc.
Well, yeah, okay. Templates do that...
> > > Well, as I said above, I guess the problem is when the > dogma is mistaken. > > Yes. And that is often subjective.
Well, I'm not that much of a relativist. I do not think that all ideas and approaches have equal merit. Some approaches are more promising than others and will typically work better. I do not claim to be in the possession of absolute truth about this, mind you, but I think there is something more or less like an absolute truth out there. I mean, which approach works better in practice, is, in principle, an empirically resolvable question.
> > > > I used 'purely practical', as you mentioned that while > you believe a strict separation is a good thing, it is not > practical. > > I never said exactly that, I don't think. > > Not exactly, but it was what I picked up from your blog > and later replies. But please do correct me if I'm wrong.
Okay, let me correct you on that. You're wrong.
To you, it seems that separation of concerns is not having any programmatic logic in your templates. To me, it has more to do with not exposing inappropriate things to the template layer -- direct SQL query capabilities and so on. Logic that pertains to presentation, it seems to me that this is best dealt with on the template layer.
> > > It's that I differ with you on what that model-view > separation means. > > Well, yes. Like I said earlier it depends on what you > think is a useful separation of concerns. I don't believe > that there is one correct answer to that, just choices.
Well, as I said above, I am not so much of a relativist.
> > > > > Well, that just depends. I have to say I don't find > the > > > case of where you develop a site, and then later pull > a > > > copy of that site and localize that just using your > > > designers and 'website integrators' (and deploy it as > a > > > seperate instance?) very convincing. > > Why not? Because they don't need you? :-) > > No, that has nothing to do with it. What I don't find very > convincing is that you would branch of your site because > you localize it, and that rather than localizing it in a > generic way you would opt for changing the templates > directly.
I am not sure I understand the above distinction.
> Not convincing doesn't mean impossible though. > If that would be a real case for you, that's cool. > > > Similarly, why should people have to rebuild or even > restart some web app just because they tweaked a few > templates? > > Then we also have very different ideas on how to manage > deployments. I'm not in favor of organization heavy > processes, but I believe any version you deploy should at > least have gone through a process where you run some unit > tests, possibly some integration test, and possibly a more > formal verification procedure.
To me, it's a question of contracts. If there is a basic contract set up that certain data structures are exposed to certain templates, as long as you don't alter that contract, there should be no need to rebuild, or even restart the system when you modify the templates.
It is borderline incredible to me that you think that you should have to restart the world from zero just because a template was changed.
> Also, working with such an > automated process makes that your deployments are > reproducable and if needed can be rolled back in a > controlled manner. Of course, even on this you don't have > to agree.
Well, I'm not 100% sure of what you're even sayng. I'll simply re-iterate that changing the presentation layer should not require a whole rebuild of the system. In fact, I'd say that's FUBAR, completely unacceptable.
> > > I mean, frankly, the things you say just start amazing > me to an increasing extent... > > Well, you can create new builds, I guess. But not > everybody who just tweaked a template is in a position to > rebuild or even restart the app. It is beyond me why you > think that should be necessary anyway. > > Heh, you can say that again :)
|
|