7 ms·

The examples uses Clojure as the language for defining the HTML. I've also seen Common Lisp examples (such as in Practical Common Lisp, http://goo.gl/CuUZQ http

by vetler 15y ago

The examples uses Clojure as the language for defining the HTML. I've also seen Common Lisp examples (such as in Practical Common Lisp, http://goo.gl/CuUZQ http://goo.gl/CuUZQ) that use CL for the same purpose. In frameworks built for other languages, it is most common to have a separate template language for defining the HTML. It seems much easier to use the same language when using a Lisp dialect compared to for instance Java, which would be a lot more verbose, but it is also done this way to separate logic from presentation, and because it's (supposedly) easier for front-end developers. Coming from non-CL frameworks, it was natural for me to choose a template framework for my small (and now outdated) tutorial on writing a blog in CL (http://goo.gl/YHCw http://goo.gl/YHCw). However, I'm wondering if anyone has any experience developing web applications using a Lisp-dialect for generating the HTML (as Noire and the example in Practical Common Lisp), and if this is scalable to a team where front-end developers might not be used to or familiar with Lisp. The syntax seems easy on the eyes, so perhaps it's not such a big problem once they get over the unfamiliarity.

timclark 15y ago
That will depend very much upon your HTML developers. Some will be able to do it, a large number will not. Even when using simple template languages I have experienced the I didn't understand those funny bits in the HTML so I have removed them far too many times. In Clojure, Enlive (https://github.com/cgrand/enlive https://github.com/cgrand/enlive) is a better solution because the HTML remains as HTML.
- markokocic 15y ago
  Is anyone aware of something similar to enlive in pure Java? I would certainly like to give it a try.
  - SergeyHack 15y ago
    Wicket and Tapestry are trying to do the similar thing. Not as good as Enlive though.
- ibdknox 15y ago
  I agree that it depends pretty heavily on who is doing your HTML. That being said, you can just not use the defpartial stuff and instead include Enlive to use with Noir just as well. There are purposefully no constraints on what you use to generate HTML. The main purpose of settling on Hiccup in this case is to provide something that I think the Clojure web community desperately needs: a single place to start and build something. The only way I can provide that start pointing is by making some choices and running with them. Also, I really love html functions as opposed to JQuery-esque template filling. It's cleaner and more flexible to me.
- weavejester 15y ago
  The main advantage of writing HTML using a tool like Hiccup is that you can factor out repeated sections of markup into functions. For example, one might write a page like: (defn user-settings [user] (settings-for [user] (breadcrumbs (link home) (link settings)) (text-field :login) (text-field :email))) And the functions used would take care of generating the page, layout, form, fields, error notices, flash messages, CSRF protection and so forth. By the time you've finished with all that, those 4 lines of Clojure will be 50 lines of HTML. Hiccup tends to lend itself toward user interfaces that are uniform and predictable, with repeatable elements. Think Facebook or Github, for instance.
  - swannodette 15y ago
    I don't see how this any different from what Enlive provides. Enlive templates/snippets create functions which generate HTML. In anycase, using Hiccup with Enlive seems to combine the best of both worlds.
    - weavejester 15y ago
      HTML is a markup language, rather than a Turing Complete programming language, so there's a lot of redundancy in a HTML file that could be avoided in a programming language. You can get around this in Enlive and other HTML-based templating methods by taking a hybrid approach. The layout HTML is written by a designer, but all the tedious repeatable elements are written by programmers in helper functions, or factored out into dozens of smaller templates. I'm not sure I like this approach, as it (a) glues together several different methods for generating HTML, (b) encourages people to write the HTML around the page design, rather than treating HTML as purely semantic markup. I admit to being something of a purist when it comes to HTML. I'd prefer to keep the style and design of the page out of my HTML as much as possible; idiomatic HTML should be semantic markup, whilst the design of the page should be defined in CSS.
      - swannodette 15y ago
        I don't see anything in Enlive which is at odds with your viewpoint.
Autre 15y ago
The same philosophy is applied in the Seaside framework for Smalltalk. See for example [1]. [1]: http://onsmalltalk.com/page-templates-and-seaside http://onsmalltalk.com/page-templates-and-seaside
draegtun 15y ago
The examples uses Clojure as the language for defining the HTML See this Stackoverflow question... CL-WHO-like HTML templating for other languages? (http://stackoverflow.com/questions/671572/cl-who-like-html-templating-for-other-languages http://stackoverflow.com/questions/671572/cl-who-like-html-t...) which provides some examples in other languages. However, I'm wondering if anyone has any experience developing web applications using a Lisp-dialect for generating the HTML (as Noire and the example in Practical Common Lisp), and if this is scalable to a team where front-end developers might not be used to or familiar with Lisp. I like keeping the HTML markup within the back-end developers domain and leave the front-end developers/designers to just use Javascript & CSS around it. (disclaimer: In most cases I'm both the back-end and front-end developer :)
oconnore 15y ago
If a front-end creates a mockup using a certain DOM, it is easy for the back-end to generate that DOM (or tell the front what needs changing). If the back-end generates a DOM, it is typically easy for the front-end to create CSS/Javascript to fit (or tell the back-end what needs changing). Also, learning that (:a :href uri name) maps to <a href=uri>name</a> is not hard, so usually the front-end will be capable of making basic changes. It is not a significant obstacle.

by vetler 15y ago

timclark 15y ago

That will depend very much upon your HTML developers. Some will be able to do it, a large number will not. Even when using simple template languages I have experienced the I didn't understand those funny bits in the HTML so I have removed them far too many times. In Clojure, Enlive (https://github.com/cgrand/enlive https://github.com/cgrand/enlive) is a better solution because the HTML remains as HTML.

markokocic 15y ago
Is anyone aware of something similar to enlive in pure Java? I would certainly like to give it a try.
- SergeyHack 15y ago
  Wicket and Tapestry are trying to do the similar thing. Not as good as Enlive though.
ibdknox 15y ago
I agree that it depends pretty heavily on who is doing your HTML. That being said, you can just not use the defpartial stuff and instead include Enlive to use with Noir just as well. There are purposefully no constraints on what you use to generate HTML. The main purpose of settling on Hiccup in this case is to provide something that I think the Clojure web community desperately needs: a single place to start and build something. The only way I can provide that start pointing is by making some choices and running with them. Also, I really love html functions as opposed to JQuery-esque template filling. It's cleaner and more flexible to me.
weavejester 15y ago
The main advantage of writing HTML using a tool like Hiccup is that you can factor out repeated sections of markup into functions. For example, one might write a page like: (defn user-settings [user] (settings-for [user] (breadcrumbs (link home) (link settings)) (text-field :login) (text-field :email))) And the functions used would take care of generating the page, layout, form, fields, error notices, flash messages, CSRF protection and so forth. By the time you've finished with all that, those 4 lines of Clojure will be 50 lines of HTML. Hiccup tends to lend itself toward user interfaces that are uniform and predictable, with repeatable elements. Think Facebook or Github, for instance.
- swannodette 15y ago
  I don't see how this any different from what Enlive provides. Enlive templates/snippets create functions which generate HTML. In anycase, using Hiccup with Enlive seems to combine the best of both worlds.
  - weavejester 15y ago
    HTML is a markup language, rather than a Turing Complete programming language, so there's a lot of redundancy in a HTML file that could be avoided in a programming language. You can get around this in Enlive and other HTML-based templating methods by taking a hybrid approach. The layout HTML is written by a designer, but all the tedious repeatable elements are written by programmers in helper functions, or factored out into dozens of smaller templates. I'm not sure I like this approach, as it (a) glues together several different methods for generating HTML, (b) encourages people to write the HTML around the page design, rather than treating HTML as purely semantic markup. I admit to being something of a purist when it comes to HTML. I'd prefer to keep the style and design of the page out of my HTML as much as possible; idiomatic HTML should be semantic markup, whilst the design of the page should be defined in CSS.
    - swannodette 15y ago
      I don't see anything in Enlive which is at odds with your viewpoint.

Autre 15y ago

The same philosophy is applied in the Seaside framework for Smalltalk. See for example [1]. [1]: http://onsmalltalk.com/page-templates-and-seaside http://onsmalltalk.com/page-templates-and-seaside

draegtun 15y ago

The examples uses Clojure as the language for defining the HTML See this Stackoverflow question... CL-WHO-like HTML templating for other languages? (http://stackoverflow.com/questions/671572/cl-who-like-html-templating-for-other-languages http://stackoverflow.com/questions/671572/cl-who-like-html-t...) which provides some examples in other languages. However, I'm wondering if anyone has any experience developing web applications using a Lisp-dialect for generating the HTML (as Noire and the example in Practical Common Lisp), and if this is scalable to a team where front-end developers might not be used to or familiar with Lisp. I like keeping the HTML markup within the back-end developers domain and leave the front-end developers/designers to just use Javascript & CSS around it. (disclaimer: In most cases I'm both the back-end and front-end developer :)

oconnore 15y ago

If a front-end creates a mockup using a certain DOM, it is easy for the back-end to generate that DOM (or tell the front what needs changing). If the back-end generates a DOM, it is typically easy for the front-end to create CSS/Javascript to fit (or tell the back-end what needs changing). Also, learning that (:a :href uri name) maps to <a href=uri>name</a> is not hard, so usually the front-end will be capable of making basic changes. It is not a significant obstacle.