common lisp expand a list inside a macro

Question

I am trying to write something similar to the routes file of ruby on rails in common lisp for the hunchentoot server, ie,

(route "/home" :controller home :action index)

with a sample controller file being something like this:

;;; controller file

(defun index ()
  ;; do something
  )

(defun add (x)
  ;; do something
  )

The reason for this is to separate the controller from the view.

So, I have the following functions:

(defun build-handler (controller action)
  (intern (concatenate 'string (symbol-name controller) "-" (symbol-name action))))

(defun format-view-file (controller params)
  (let ((fstring (read-from-view-file))) ; the view file must be named after the controller. the details are not shown here
    (format nil fstring params))) 

(defun get-action-arguments (f)
  ;; read the controller file 
  ;; and find the action function
  ;; return a list of its arguments
  ;; something like this, in case f was "(defun bar (x) (1+ x))"
  (car (cdr (cdr f))))

and the macro:

(defmacro route (uri &key controller action)
  (let ((var (build-handler controller action))
        (params (get-action-arguments action)))
    `(hunchentoot:define-easy-handler (,var :uri ,uri) ,params
                      (setf (hunchentoot:content-type*) "text/plain")
                      (format-view-file ,params))))

My problem is I cannot pass params around correctly. How should params be inside the route macro?

Alternatively, is there a better way to accomplish this or is there a library that works on top of hunchentoot (I found some but don't know which one to choose, so I started writing my own).

Thank you very much in advance!

Answer 1

Just a few pointers, there are more:

There is a nice server abstraction layer called lack: https://github.com/fukamachi/lack .

With it, you can quite simply build your own routing mechanism, or use the existing ningle or caveman.

There is also RESTAS , which builds directly on Hunchentoot.

As for your idea: I strongly advise against file loading/filename mangling magic for language mechanisms. You should be able to express anything in terms of simply loading toplevel forms, so that you can layout your entire application structure in a system definition and, most importantly, keep the simple image based development cycle. Your code should not need to know that it is being stored in files.