I'm not criticizing Noir's decision to couple the traditional MVC
controller and view logic. This works well for small sites, which
seems to be Noir's primary use case right now. The problem is the
simply the name. If your site grows bigger, you'll probably move
toward the MVC architecture, and you'll have to juggle the concept of
a Noir view and and MVC view during the transition. Any reference to a
view in the Noir documentation is a mental switch from what most
people already know as a view.
This raises a question: what is Noir's intended place in the world of
web frameworks? Is it like Sinatra, where you build a small site and
eventually grow out of it, or is it something you can continue to
build on top of as your site gets more complex? As the author has
mentioned in the discussion group, decoupling Noir's components is
trivial. I think large sites and frameworks could use Noir as another
layer in the onion (as someone in #clojure IRC put it), similar to
Ring's use case.
We could make this happen and still support smaller sites. The
controller and view can still be coupled by default, but these
functions should not be called views. I haven't thought about a better
name too much (actions? pages, as in defpage?), but I wanted to raise
the issue, as I think it could confuse new users, especially those
coming from traditional MVC frameworks.
Here's an example: if you prefer to put your controller logic in
separate files, you're going to get something like this in your
server.clj as of Noir 1.2.1:
(server/load-views "src/my-app/controllers/")
If you're not familiar with Noir, this is nonsense.
In an article on using Continuations and Monads for building a Web
Framework Jim duey writes:
" ... a web app isn't just a web app. If you step back a little,
you'll see
that a web app is actually a finite state machine. At each state of
execution,
it accepts new input and returns a result. If you renamed the
functions, this
library would be one way to define and execute state machines. This is
now
the third way I've come across to represent FSM's in Clojure in a
concise way."
is a dedicated FSM (plugable) perspective or anti-pattern ?
(in my experience, use of FSM for implementing simple web-apps
complicated things ... i am not experienced in implementing
big webapps though)
noir is at a high level, but still duplication exists and rates of
reuse could probably be increased.
to simply 'use a FSM' seams to complect things at some point.
it may be, that the integrative aspects of monads can help to realize
'is a FSM'. to have a ControllerAndView would not necessarily
constrain reusability then.
-> copy and transform like a painter who looks at
works of other painters and gets inspired ?
(recognizable patters must exist, the simpler the better)
you could say to your web-app: 'get inspired by
the other web-app' or 'sync with recent changes'
-> supervised learning process.
if unsupervised, it would be a process similar to
reproduction of life. but random output is probably
not something a programmer wants.
(sorry for the digressiveness)