In object oriented languages, there is always one master class that all the other classes inherit from.  There is a root in the inheritance tree.  In ruby, this is the Object class, in content we propose the Card.  Developed in the context of a rails web application that shares and extends wiki concepts, cards are designed to support web interfaces and wiki practices, but as we shall see along the way, each of these features can be considered and packaged as optional components in a much larger space of applications development.

This content model was developed inside a particular web application, specifically a ruby and rails application with its MVC pattern.  We began to notice a new pattern developing where the controller is cannonical, serving up pages or data according to a ReSTful protocol, and application development can be concentrated on implementing models and views.  Actions are customized in events at specific times in the object life cycle.

Although the view process might need to reference controller actions in providing controls linked to them, we abstract that away in Formatters that can be defined according to the application's needs.  The initial web application focused on rich html views that are matched with some front-end code, but a formatter can be defined to output json or xml, or even the ruby objects that would serialize into that data.  Cards are not dependent on a web applicaiton context, but they are great for implementing one.  Implementing text formatters for email and print use, and data formatters for AJAX friendly formats like JSON or XML gives a wide range of choices to the application architect.

We begin an exploration of the entire architecture from the bottom up.  Along the way we will see how each feature supports the entire design while remaining distinct, and each is an axis of flexibility for the architect to extend the platform.  The system of naming data supports wiki-style linking of content, as well as the URI namespace used in web contexts.  It also is part of how you can specify rules in data, and other extensions in code according to a system of sets.  The names for data in application space (cardnames) map consistently to code namespaces  Not only does this fascilitate the creation of modular extensions, new code, but it can support modular systems architecture where an application is a network of services.

We don't know what to call this pattern yet, is it MoVE for Model, View, Event, or is it MoFoS for Model, Formatter, Sets?  Whatever you call it, it represents a significant departure from the MVC pattern; something that fits well with the MVC pattern, but also moves closer to a user oriented model of connected data from the tabular architecture of relational databases.

I am setting out to describe this architecture, not to document it.  It is an exploration for all of us.  If you are a systems architect, you will learn how to apply this technology effectively and possibly help define it, and if you are a user of card based systems (Decko) I hope you will be able to understand it better at the level you encounter it and help us to make it more comprehensible for all, users and builders alike.  Module and core developers are not far below the architects, and our data programmers (see Sharking) will find much of interest, but when designers, editors and product managers can understand how it empowers them in applying technology I will have met my goal.

Each axis of flexibility provided by the architecture is an opportunity for designers as well as architects.  The designer can directly extend and modify the details of the implementation in data and if not directly in code, close to it because the small amounts of code in many modules are easy to repurpose.  The architect can concentrate on flexible and stable systems.  Designers and module coders will know what they can ask of architects and what features that the architecture naturally supports.  Designers can create working prototypes from existing module libraries while doing iterative development with UI and domain developers to refine the system.  At the other end of the scale the architects and systems programmers and engineers who can deploy card based components in a flexible networked applications architecture.