Concepts

Cards

The most important Decko concept is the cards. Cards are the basic building blocks of Decko websites, or decks.

Cards are inspired by wiki pages. Like wiki pages, cards have revision histories, human-friendly names, and easy in-place editing interfaces. But we don't call them pages, because the word page already has a pretty clear meaning on the web: a webpage. On Decko, a given webpage might be constructed out of dozens or even hundreds of cards. Cards not only hold lots of different content that can be combined and recombined in flexible ways, they also determine how a webpage is structured, who can read it, and how it behaves.

In Decko, everything is a card: images, users, files, layouts, searches, lists... they're all cards. In fact, each of those is a Cardtype. Every card has a type, which, among other things, determines what kind of content the card has. It's very easy to create new cardtypes; you just create a new card with the type "Cardtype". 

Cardnames

If you're thinking that you've heard this "everything is a X" story before, then you're right. Wordpress says that everything is a post. Drupal says that everything is a node. And so on. But Decko takes the idea further. When you break a Wordpress post into smaller bits, you get something that is not a post. Same for a Drupal node. But when you add more granularity to cards, you get more cards.

The key concept behind this niftiness is Decko's use of patterned names. Like any wiki, every Decko card has to have a unique name. Unlike most wikis, you can combine card names to form meaningful compound names. For example, if you have a card named "John" and one named "image", you can combine the two to form a new card named "John+image", a child of both "John" and "image". 

This simple notion provides the basis upon which Decko structures can be created. You can use naming patterns to create all kinds of rules, for example to add a +image field to all User cards. You can then write queries to find all users with or without an image. You can also add more names to create new compounds, for example to discuss John's image at "John+image+discussion".

Nesting and Views

To make sense and make use of all these cards, we must be able to connect them to each other. You can do so in the traditional web/wiki sense by linking them with hyperlinks, of course. More unusual is Decko's deep reliance on nesting, in which one card visually includes another.

What exactly is included depends on the view. If you nest a card in "content" view, for example, you will see only its content. In "name" view only its name. But there are many other views built-in, some with both name and content, some with metadata, some with functional interfaces, etc.

It's possible to nest cards anywhere. For example, we can nest the logo card in "box" view here:

...but the more exciting nests are patterned nests, and for those you need rules.

Sets, Settings, and Rules

rules are cards that apply a given Setting (or Rule Type) to a given Set of cards. For example, if I wanted to make it so that only John could read all the cards on my deck, I would make a rule that applies the read Setting to the Set of all cards. Underneath the hood, this is done by reusing concepts we've already learned: the card :all+:read uses the compound name to connect the :read setting to the :all rule. If its content is John, then by default only John can read all the cards in the deck.

In practice, nobody writes these rules by typing in card names; there's an interface that makes this much easier to manage. But this example demonstrates how far Decko goes to follow its "everything is a card" rule. Even rules are cards! And, as a side benefit, you can do everything with that rule that you can with any other card; view it as a webpage, query it, edit it, view its revision history, access it via an API, etc.  Well, you can do that if you're John and have permission.

Rules are made to be overridden, however, and rules on narrower sets override rules on broader ones. So you can, for example, restrict edit permissions on all cards to one group, all image cards to another, and a specific image to a third.

This rule pattern extends to permissions, structured content, layouts, events, help text, and more.