Christophe Grand wrote: > > Therefore, this feels a bit misleading to me: "this separates design > > from code even further". I just want to point out StringTemplate helps > > separating design from code, but its main goal is separating the View > > from Controller and Model in a formally strict way. In the case of > > enlive, this main goal is not achieved, so it couldn't be done "even > > further". > > I think you both aren't talking about the same separation: > - (To put it in MVC terms) Enlive separates the View into design (plain > html, no extra tags, no $..$) and code (clj) > - StringTemplate enforces a strict separation of the View from Model and > Controller.
Not really. What you perceived as such is because of my bad attempt at saying the following. The html-clj separation is completely distinct from StringTemplate's v- mc separation. Therefore, it feels a bit misleading to compare them using such relation as "even further"; it diverges one's thinking from either real goal of Enlive or S.T.: Enlive's real goal is, in the View, to separate design and code. In fact, Enlive looks really great here. And ST fares better on this aspect than most other templating libraries, but it's only one of the consequences of enforcing ST's real goal. If one thinks in terms of "Enlive goes even further than ST at separating design from code", one might completely overlook the real goal of ST. ST's real goal is to separate the View from Model and Controller (VMC/ MVC). In my understanding, Enlive doesn't try to enforce this at all. Consequently, most projects using Enlive will "feature" intertwined VMC aspects in the code of their V, because it's really hard not to cross the line. Therefore, if one thinks in terms of "Enlive goes even further than ST at separating design from code" and thinks of design as V and code as MC, one will end up with a false conclusion. Now, I must confess that I kind of jumped on the issue because I had just read the paper and felt the phrase misleading. I might as well have let it like it is and nobody would have suffered much about it. :) This being said, I didn't doubt that Stuart's intention was to mean literally html-(code-in-the-view) separation. Sorry that it looked like that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
