CRATES is a very lightweight, extendable, open .php framework and a set of efficient design patterns for processing and displaying content, similar to MVC.
The fundamental parts are:
User content: The actual files or data created by the user. Whatever. Really, whatever. Images, music, text, dynamic content from external sources, whatever.
Metadata: Information intrinsic to the content and/or provided by the user about both the individual files and the group as a whole.
Content Procesors: Scripts which look at the content and metadata and do something with or to it, outputting an array of the results.
Content Interpreters: Scripts which look at the content and metadata and format it according to a human-readable template.
Metadata Reporters: Scripts which send the <meta> node, <content> nodes, or content-files of a CRATE to other organizational platforms or systems (databases, social networks, etc). Default reporter creates a master .xml file of all <meta> nodes.
The Cratr: A standardized series of scripts which provide a user dialogue and coordinate content and metadata with Processors, Interpreters and Reporters, outputting -- at the very least -- in the individual CRATE’s directory the metadata as crate.xml and the template as index.php. Currently ~ 65 kb of code (excluding standard Processors and Interpreters).
If this sounds very general, that’s because it is. Each one of these stages is customizable and extendable. As long as you adhere to a few basic conventions, you can make processors that do whatever you want, interpreters that look the way you want, and reporters that send the data wherever you please. Once you do, it will all be automated, reusable, remixable, and part of a very flexible framework.
Simple example:
Right now, there are only a few interpreters and processors for CRATES, and they mostly deal with images . That’s because I mostly deal with images, and the things I wanted to do with them online led me to write CRATES. I found a php script that reads IPTC data (thanks to Joshua Heiland) and put the heart of it into a complicated script that checked files against an array of accepted types and looped through directory structures and then compared output against another array and so on. Of course, as soon as I got it working, I thought of other things I wanted to do like it. Trying to stick to the mantra of never typing the same thing into a computer twice, I cut out everything but the integral part of that script and wrote CRATES to handle the rest of the process. Now, just like how CRATES users only have to point the system at their well-described content to integrate it, CRATES developers only have to point the system at their well-described scripts, .css, and markup.
What Makes CRATES different?
CRATES doesn’t have any cutting-edge code or many new ideas; it’s got room for cutting-edge code and new ideas. Anything you can write in php -- or to communicate with php -- can work with CRATES, and anything that can read xml can read CRATES output. Class integration is simple, all markup is extensible and basic, and it’s designed to be database-agnostic (and is currently database-atheistic).
CRATES is built to manage and remix whatever it is that you do.
How do you use it?
There are two ways to work with CRATES as a developer.
1) Extending
CRATES functionality can be extended at each stage of the process with php files described by specially-named xml. The three stages are Processing, Interpreting, and Reporting.
Once you’re familiar with the three stages of creating a CRATE, you could write a new Processor / Interpreter pair for a new Content Type, or you could write a new Processor or Interpreter for the two existing Content Types (IMAGE and LINK). Additionally, you could write a new master.php for interpreting master.xml.
The CRATES alpha doesn’t yet support custom Reporters.
2) Refining the Cratr
Of course, the Cratr -- the series of forms and generate.php -- needs work too. I plan to install TRAC on cratr.org to handle development of the Cratr code. For now, see the roadmap or send me an email.
What’s Next
New ideas about Content
New levels of content organization: Standardized filetypes, semantic markup, and systems like RSS are helping to organize the web on a granular level. At the level of groups of standardized content, popular communities like Flickr and Facebook have nearly created a standard for things like photo albums and personal data, but these are standards within fairly closed systems. There is no open standard for how to group and share images, no open standard for how to group and share profile information. There are standards within defined communities, and efforts to create standards, but nearly no functional internet-wide standards exist at a content-group level. CRATES can provide a means to translate between an unbounded set of conventions at this level -- from text to Facebook to MySpace to the next big thing, or vice versa. Through this potential, CRATES has the power to create standards at this level.
A new concept of what is “content”: By creating dynamic processors or reporters, we could begin to develop new ways of dealing with the material on the internet that matters to us. Widespread adoption of RSS and other blogging conventions facilitated an explosion in blogging culture and allowed changing streams of content to be manipulated as discrete entities -- bookmarked, centralized, forwarded, subscribed to, visualized, searched, tracked, etc. We could see similar shifts with CRATES which process dynamic content (such as scraping data from a range of sources) and CRATES which automatically update a range of destinations (such as a custom combination of a user’s accounts on existing networks). Or we could see entirely new things.
Community
To reach its potential, CRATES needs a community. Once the Cratr is refined and one or two truly-useful extensions exist, I’m planning a beta release which which will register authors, extensions, and individual CRATES with a central server (as a default, but not a mandatory default). Besides encouraging a community of categorized, open, and accessible content and code, this has the following benefits:
Collaborative Content-Type integration: Content within CRATES is organized based on the name of its individual node -- it’s Content Type -- within the CRATE, eg:
<crate>
<content>
<[name]_type>
<[name]>
...
This markup is open, but with a development community, common types and defaults can be refined and developed.
Meta, meta, meta: Whatever you can put on the internet, you can put in a CRATE. So if you see something being done with networked content somewhere else, it could be done with CRATES.
For more, see the Roadmap.