Hi...still new to arc. Would like to tinker with it a bit.
Before I go down that path... does arc have a templating language?
I'm coming from railsland. To be honest, I really can't see writing a web app without some kind of layout/templating framework for generating html. (maybe i'm missing something)
It depends what you mean by templating language. Arc already provides a means to create different reusable layouts and wrap output in them. The HTML-generating macros act a lot like templates. You can see how they work in the blog example that comes with Arc.
I actually much prefer Arc's method. Templates of the traditional variety are just so clumsy. It's hard to build abstractions using them; it's hard to document what you're doing with them (what local variables does this partial template require?); they end up being scattered around in a gazillion files the names and locations of which are hard to remember; and the coupling among templates and various other parts of the framework makes it really hard to test them in a REPL.
In Arc, just use functions. You'll have better abstractions, better testability, and better organization. A function that generates one line of HTML will just be a function in a library of functions rather than a tiny template in its own file.
Of course, that means that any designer has to be fluent in Arc's libraries as well.
Not to suggest that Arc's method is anything short of perfect for what Arc does, but a big benefit of MVC is how separation of logic and presentation reflects separation in personnel.
The seperation of logic and presentation doesn't belong between code and HTML, it belongs between HTML and CSS. HTML is best controlled and generated programatically. Arc does it right, Rails does it wrong.
I'm not sure what your professional experience making websites is, but mine has shown me time and time again that making good looking sites is an iterative process full of workarounds for real-world considerations.
The method you're suggesting would make it excruciating to converge on a good design with any real designer. Look at the markup any good looking and well-implemented web page (especially one with dynamic content), and you'll see a huge amount of extra tag work to accommodate the real world of cross-and-backwards-compatibility between browsers, CSS limitations, browser quirks, and other concerns that people making professional sites require.
If every one of these changes and workarounds required changes to the code, which would require my time instead of the designer's time?
The Rails way is just copying a method that nearly every web toolkit uses, and they use it for a reason. Arc's way may be cleaner, but without a templating language it will be at a disadvantage.
- If you get the layout, including both how it should look and how things should work, from an external source, or if there is substantial external input, use templates. It will save time and headache.
- If you are just about the only one responsible for the layout but support skins (for lack of a better word; the CSS part), use the HTML tag functions and macros embedded in Arc.
Since Arc is at this point targeted for exploratory programming, the former is an unlikely case.
What I would like to see, though, is a templating engine akin to HTML::Template [1] in Perl 5. It has the minimum of control structures and extra syntax on top of standard HTML, just enough to make it possible to use the template for dynamic content. All templating frameworks suffer from the same fault, though: they define a new but severely restricted embedded language that's mixed in an unpleasant way with the HTML source. The language embedded in Arc is a much cleaner way to do things.
Complex designed websites are pretty much impossible using Arc's current library. Well, unless you're a programmer/designer with a high pain threshold.
When Arc is no longer classified by whatever greek letter comes before alpha, it might be worth investing into a nice way to separate out some MVC/MTV/VH1/&c.
I'm coming to Lisp from over ten years of Blub programming - C++, Java and C#. For what it's worth, I think templating languages are an evolutionary dead-end. Templating languages are seductive, because you see all this static HTML, so you think the right way to go is to serve up a template where you drop in the dynamic bits. But then you have to add another dynamic element, and another dynamic element, and pretty soon you have this awful mess that you can't easily modify or debug.
You just do your own separation of logic & design, using Arc as the template language. I know it sounds PHP-esque but in practice it seems rather elegant so far.
e.g.
;; the controller-ish part
(defop problems req
(display-probs (get-user req)))
;; the view-ish fn
(def display-probs (u)
(mypage ; a layout-ish macro
(each id (keys probs*) (display-prob u (probs* id)))))
;; a partial-ish fn
(def display-prob (u p)
(tag (div class "prob")
(tag (span class "pid") (pr (p 'id) "."))
(tag (span class "text") (pr (p 'text)))
(tag (div class "links")
(let bar* " • "
(w/bars
(link "details"
(string "http://someurl/foo?bar=1&id=" (p 'id)))
(link "solve" (newsolnlink (p 'id)))
(link "solutions" (solnlink 'p (p 'id))))))))
Not yet, although it should be possible. Show us how you expect to define a template (using just s-expressions, unfortunately), and we'll try to hack something that can read your code.
As the primary developer of Haml, I'm playing with the idea of porting it to Arc at some point (likely not via sexprs, though, because a large portion of Haml's coolness comes from other aspects of its terser syntax).
