Before making any code change, it is important to clarify the conceptual modules in zena and their dependencies on a framework. This is the goal of this article.
controllers
Do we need a DocumentsController ? What is it used for ?
application
What is the code in there doing ? How does it rely on rails ?
models
The models are quite properly defined. The places where the relation to the framework is messy are:
- validation workflow (rails,secure,multiversion)
- auto-saving of sub-models (version,content)
- attribute get/set (multiversion,linkeable)
rendering
Conceptual clarification needed between the different components:
- controller (finds the right template)
- zafu (build erb template)
- helpers (during compilation, during rendering)
other areas
authentication
It would be nice to be able to use about anything. This means that the relation between the visitor and it’s node needs to be decoupled (trying to clarify “visitor”). Zena should be ready to support LDAP through a simple plugin for example.
skin import
This works pretty well except for classes and relations definitions. Maybe it would be good to include a special field on a skin’s zml file with the relations and classes it needs to work properly. We should then find a way to ask the user if she wants to create these relations/classes. A link after import could point to relations/classes where the proposed new elements appear in grey.
backup (move)
A site owner should be able to ask for a full backup of the site. This backup should be importable in another (possibly empty) site without too much trouble.