What to expect from Compojure 0.4.0
James Reeves
has now been done, and if all goes according to plan, it will be
released in the next month or two.
The 0.4 branch will break backward compatibility with 0.3. I'll
maintain 0.3 in a separate branch, and continue to accept bug fixes,
but I'm not going to add any new functionality.
So what's so different about 0.4.0?
== 1. Reliance on Ring for all HTTP ==
The first major change is that Compojure will now rely on Ring for all
basic HTTP operations. A lot of Compojure middleware has been improved
and integrated into Ring, including support for urlencoded parameters,
cookies, sessions, and Java servlet compatibility. Multipart
parameters and smart static file serving should be forthcoming.
Ring is a very nice platform to base a web framework on. It's simple,
elegant and extensible. With the new set of middleware that's going to
be in 0.2, all basic HTTP functionality should be covered.
== 2. No included HTML generating library ==
Version 0.4 will not include anything libraries for generating HTML,
as compojure.html does currently. It'll be up to the user to include
the HTML library of their choice. Enlive and Fleet are two possible
options for those who prefer to work with HTML templates.
However, compojure.html has not gone away; it's been refactored out
into Hiccup [http://github.com/weavejester/hiccup]. Hiccup is not only
several times faster at generating HTML on the fly, it also pre-
compiles your tag vectors whenever possible:
user=> (use 'hiccup.core)
nil
user=> (macroexpand-1 (html [:span "Hello World"]))
(clojure.core/str "<span>Hello World</span>")
user=> (macroexpand-1 `(html [:span #^String message]))
(clojure.core/str "<span>" user/message "</span>")
The end goal is to make Hiccup as fast as Mark's clj-html (when type-
hinted), but without losing any of the benefits of a dynamically
generated html function. Hiccup currently passes all of the unit tests
that compojure.html passes, so you should be able to slot it in
without altering your code.
== 3. No more magic variables ==
In 0.3, Compojure provided several magic variables, like "params" and
"session". In version 0.4, these will be replaced with a binding form.
To access the parameters directly, you can destructure the map:
(GET "/hello/:name" {params :params}
(str "Hello there " (params "name")))
Or if you just want to access certain parameters in the map, you can
do:
(GET "/hello/:name" {{:strs [name]} :params}
(str "Hello there " name))
Or, with a touch of syntax sugar, this:
(GET "/hello/:name" [name]
(str "Hello there " name))
The last example demonstrates a bit of Compojure-specific syntax
sugar. If Compojure detects a vector, instead of a map, it will assign
the parameters to each value of the vector.
== 4. Route syntax handled by Clout ==
The final change worth noting is the route syntax (i.e. "/
hello/:name") will be handled by my Clout library. This currently
allows a little extra flexibility if you compile the routes manually:
(GET (route-compile "/product/:id" {:id #"\d+"}) [id]
(get-product-by-id id))
In future, I'll be extending Clout to support more sophisticated
routing syntax, so you'll be able to write regular expressions inline:
(GET "/product/{id:\\d+}" [id]
(get-product-by-id id))
== 5. Better website documentation ==
Okay, not quite the last change. I know I've promised better website
documentation for a while now, but in this case I think I mean it.
Because most of Compojure's current functionality is being factored
out to Ring and Hiccup, the actual functionality specific to Compojure
should be quite small. Documenting a huge library is daunting, but in
0.4, Compojure will have slimmed down considerably.
Or, to look at it in a more cynical fashion, I'm foisting off
documenting middleware and handlers onto Ring's documentation ;)
- James
Anders Rune Jensen
This sounds really cool. All very good changes. I'm wondering if the
Ring reliance will allow one to get some kind of signal when a browser
disconnects?
Thanks
> --
> You received this message because you are subscribed to the Google Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en.
>
>
--
Anders Rune Jensen
James Reeves
wrote:
> This sounds really cool. All very good changes. I'm wondering if the
> Ring reliance will allow one to get some kind of signal when a browser
> disconnects?
You mean in terms of long-polling? Essentially no, but then there's no
foolproof way of telling an intentional user disconnect from a normal
browser timeout anyway, except by waiting to see if the the user
reconnects.
- James
David Nolen
David
Brian Wolf
To the extent you think it is appropriate, could you comment on your
direction vis-a-vis other projects, perhaps in other languages.
Thanks
Brian
James Reeves
> To the extent you think it is appropriate, could you comment on your
> direction vis-a-vis other projects, perhaps in other languages.
That's a broad question. Could you be more specific?
- James
Brian Wolf
hmm... I'm just a java programmer, honestly, most of clojure is greek to
me, but I love clojure, and compojure seems (without meaning to inflame
our ruby brethren) easier to use than RoR, just writing handler
functions, input->output, that part is very useful from my point of
view. I do think the RoR MVC concept is too rigid of categories to
me (and confusing). I'm also unlearned regarding concurrency ideas, but
( just a question!) might integrating it with a server written in native
clojure be interesting for closer integration? (like dynamically
spawning off additional servers for load balancing , game programming ,
etc) This is probably a whole other department, but thought I use the
opportunity to ask ;-)
Brian
James Reeves
> hmm... I'm just a java programmer, honestly, most of clojure is greek to
> me, but I love clojure, and compojure seems (without meaning to inflame
> our ruby brethren) easier to use than RoR, just writing handler
> functions, input->output, that part is very useful from my point of
> view.
Ruby on Rails can be quite rigid and complex, but not all Ruby
frameworks are like that. Compojure was actually inspired by the Ruby
framework, Sinatra, though it's gradually diverging from its routes
into something more suited to Clojure's functional style.
> I do think the RoR MVC concept is too rigid of categories to
> me (and confusing). I'm also unlearned regarding concurrency ideas, but
> ( just a question!) might integrating it with a server written in native
> clojure be interesting for closer integration? (like dynamically
> spawning off additional servers for load balancing , game programming ,
> etc) This is probably a whole other department, but thought I use the
> opportunity to ask ;-)
I can see a web server written in Clojure being very useful,
especially for long-polling, websockets and other HTTP streaming
techniques. But I suspect it'll be a while before I work on anything
like that.
- James
Mark McGranaghan
As James discussed, Compojure 0.4 will be relying significantly on
Ring. Compojure users might consider subscribing to the new Ring
Google Group (http://groups.google.com/group/ring-clojure), and
perhaps also tracking Ring on github (http://github.com/mmcgrana/
ring). If Compojure users have any questions/comments/concerns about
Ring or Compojure's use of Ring, feel free to post questions here or
in the Ring group. Since I'm inheriting some documentation
responsibility with the transition, I'm also interested in hearing
what sorts of Ring-related docs users would like to see.
- Mark
James Reeves
> As James discussed, Compojure 0.4 will be relying significantly on
> Ring. Compojure users might consider subscribing to the new Ring
> Google Group (http://groups.google.com/group/ring-clojure)
Ah yep, I did mean to mention that.
> Since I'm inheriting some documentation responsibility with the
> transition, I'm also interested in hearing what sorts of
> Ring-related docs users would like to see.
I have some documentation that could be adapted, but unfortunately not
that much. I was considering starting a blog with various examples of
how to do things, as it's often easier to write small articles than to
attack a whole chunk of documentation in one go.
- James
Nicolas Buduroi
Pylon framework before coming to Compojure and liked that approach to
web development. I'll certainly get back to contributing to this
project once ClojureQL is released.
- budu
On Feb 20, 12:04 pm, James Reeves <weavejes...@googlemail.com> wrote: