expand_less
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 seen 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 andrails,rails andapplication with its MVC pattern,pattern. but We 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 controlleractions,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. By implementing text formatters for email and print use, and data formatters for AJAX friendly formats like JSON or XML give 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, isisit MoVE for Model, View, Event, or is it MoFoS for Model, View,Formatter, Sets? Whatever weyou call it, we think it represents a significant departure from the MVC pattern; something that fits well with the MVC pattern, but also makesmoves acloser leap to a new level of abstraction that is further towards a complete application out of the box.
I am setting out the describe this architecture, not to document it. It is also an exploration for all of us. If you are a systems architect, you will learn how to apply this technology effectively, and if you are just a user of card based systems ([[http://wagn.org|Wagn]]) I hope you will be able to understand it better at the level you encounter it. Module and core developers are not far below the architects, and our data programmers (see [[http://wagn.org/wagneers|Wagneers]]) 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.
An axis of flexibility is an opportunity fordesigndesigners as well as architecture,architects, but they get to concetrateconcentrate on what they do best. Designers learn how to ask architects and developers for features that the architecture naturally supports. They get to work on features that support a broad range of functionality, and once deployed, the designers can create working prototypesprototypes. that Iterative candevelopment berefines furtherthe refinedsystem bothwith upactions andall downalong the scale of usage stretching from architects through develoopers and designers down to end users.
This content model was developed inside a particular web application, specifically a ruby and
Although the view process might need to reference controller
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
I am setting out the describe this architecture, not to document it. It is also an exploration for all of us. If you are a systems architect, you will learn how to apply this technology effectively, and if you are just a user of card based systems ([[http://wagn.org|Wagn]]) I hope you will be able to understand it better at the level you encounter it. Module and core developers are not far below the architects, and our data programmers (see [[http://wagn.org/wagneers|Wagneers]]) 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.
An axis of flexibility is an opportunity for