This is another core component of the card system.  Initially there was only one formatter to render different views of cards to view and edit them as components of a web page and I wanted to access cards in XML representations through a ReSTful controller.  This required a major rewrite of the current rendering code and brought in the concept of rendering to different formats.  Although we had views, we didn't yet have the system of defining views for sets, and the formatter became where the views are defined and their running context.  When support for set based views was implemented, the way they were defined and looked up was changed to support sets.  That implementation has evolved to support sets on views in a way parallel to model modules are loaded.  Global views (on *all) are still defined as methods on a formatter, but the set-based views are defined on a module just like the model methods and events.  We'll come back to this when covering code based rules in Model Views and Events.

This isn't too different than the rails system of views where the requested format is part of selecting view.  What is a bit different is the use of blocks as well as file/directory names to give more flexibility for grouping views and set code.  The view code is just blocks that return strings.  If you must have the typical view templates, that kind of view was recently implemented.

We'll have to come back to cover how views relate to each other and help application builders implement a consistent and intuitive user experience.  Views can be specific to controller actions as in edit views that will post updates as form data, or might be very simple in the case of data formatters.  The UI support the idea of open and closed views under the control of the user via standard controls.