The idea behind this framework ist that all sites are made of any number of content blocks which belong to an URL.
So the content blocks are mapped to an URL
(URL (Content-I Content-II))
An Example:
Content Block I
-------
| abc |
-------
Content Block II
-------
| def |
-------
Block I and II are bound to serverrelativ URL /content
(:/content ("Content Block I" "Content Block II"))
http://www.martin-enders.de/content leads to a page like this:
/-page----------\
| |
| ------- |
| | abc | |
| ------- |
| ------- |
| | def | |
| ------- |
|_ _ _ _ _ _ _ _|
Idea
The idea behind this framework is that you can map differnt content blocks to an url.
Problems / Questions
How should sites be treated when you use special functionality. Is in content blocks just HTMl allowed or should it be possible to integrate lisp into the pages?
The content Blocks are integrated in an layout so the HTML in the content block is just a part between the <body> and </body> tag. If you need an extra css file you have to be enabled to integrate an special tag to integrate additional information into the HTML head.
But all these workarounds lead to inconsistencies in the framework - it seems that it's not a good design now.
Conceptual Lisp Dispatcher:
(defvar *dispatch*)
(setf *dispatch* '(:/ ("index")
:/web ("web")
:/css ("css2" "css3")))
(defun get-content(content-block)
content-block)
(defun render-content(content)
(format t "~a" content))
(defun dispatcher(script-name)
"This function takes a string as argument
and converts it into an keyword for
comparison with the url's in *dispatch*"
(let* ((request (intern (string-upcase script-name) "KEYWORD"))
(content (getf *dispatch* request)))
(dolist (content-block content)
(render-content (get-content content-block)))
request))
Conclusion
I'd like to have a small consistent framework for publishing in the web. But the current state of this idea has to many inconsistences.]]>
.