Creator of the Apache Tapestry web application framework and the Apache HiveMind dependency injection container. Howard has been an active member of the Java community since 1997. He specializes in all things Tapestry, including on-site Tapestry training and mentoring, but has lately been spreading out into fun new areas including functional programming (with Clojure), and NodeJS. Howard is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Changes to Cascade, and a cautionary tale about defrecord

09.22.2011
| 3706 views |
  • submit to reddit

Since I've been talking more about Clojure lately, I've spent a little more time working on Cascade. I've been stripping out a lot of functionality, so that Cascade will no work with Ring and Compojure, rather than being in competition. Its Clojure, after all, ... there's less of a reason to build a full framework since its so easy to simply assemble your functionality from proper libraries.

It's also been a chance to update some of my code with more modern constructs. For example, the earlier version of Cascade used a (defstruct) for the DOM nodes; the new code uses (defrecord).

Along the way I discovered something interesting about defrecord. Consider this code:

(defrecord Comment [text]

  NodeStreaming
  (stream [node strategy out]
    (write out "<!--" text "-->")))

Technically, this is just an optimized way to define a Clojure Map. If I have an instance, I can (:text node) to get the text out of the map.

However, (defrecord) does one other thing that is barely mentioned in the documentation (and not referenced, that I can tell, in Joy of Clojure). Notice the implementation of the stream function (part of the NodeStreaming protocol). It just says text; not (:text node). Inside a protocol method, the fields of the record are bound to local variables, making them easy to use ... another benefit.

I actually found this the hard way, when writing a more complicated example, for the Element DOM node:
(defrecord Element [name attributes content]

  NodeStreaming
  (stream [node strategy out]
    (let [element-name (clojure.core/name name)
          attr-quote (strategy :attribute-quote)]
      (write out "<" element-name)
      ; Write out normal attributes
      (doseq [[attr-name attr-value] attributes]
        (if-not (nil? attr-value)
          (write out
            " " (clojure.core/name attr-name) "=" attr-quote (to-attr-string attr-value) attr-quote)))

      (if (empty? content)
        ((strategy :write-empty-element-close) element-name out)
        (do
          (write out ">")
          (stream-nodes content strategy out)
          (write out "</" element-name ">"))))))

Notice the use of clojure.core/name to convert a keyword to a string; originally this was (name (:name node)) and returned nil. This confused me quite a bit!

What ended up happening was that name was bound to the keyword from the record's name field. However, Clojure keywords can be used as functions,and was incidentally passed itself, which is to say (for an Element node representing a <p> element): (name (:name node)) --> (:p :p) --> nil.

So, (defrecord) giveth, but it also taketh away, at least, the first time. In other words, watch out for name collisions between the names of the record's fields, and the names of functions you want to reference from your protocol method implementations.

Back to Cascade; I don't have any metrics available about performance changes with the new code (using records and protocols), but I suspect its faster and more efficient.

A lot of the features that were in Cascade are gone and will come back soon. Ultimately, I'll have Cascade flavors of context and classpath assets from Tapestry, as well as mechanisms similar to Tapestry for adding JavaScript libraries and CSS stylesheets, along with a mechanism similar to Tapestry for organizing them into stacks.

Looking further forward, adding support for Enlive, both reading parsed XML templates in as DOM structure and allowing Enlive transformations onto the DOM structure, seems like a good direction.

When will all this happen? I'm not certain, but I hope that Cascade will become a "must-have" layer on top of Compojure, adding some of the industrial strength concepts from Tapestry into the fast-and-loose world of Clojure web applications.

 

From http://tapestryjava.blogspot.com/2011/09/changes-to-cascade-and-cautionary-tale.html

Published at DZone with permission of Howard Lewis Ship, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alexandru Repede replied on Mon, 2011/09/26 - 4:20pm

created and example out of your post on clojuredocs. mentioned your name, hope you don't mind http://clojuredocs.org/clojure_core/clojure.core/defrecord#example_748

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.