Wagn.org, GrassCommons.org, i: #wagn, Ethan McCutchen, , t: @ethosophy, s: ethan.mccutchen

Some Built-in Types

Rich text, and it's the default cardtype.  Uses a simple wysiwyg editor.

Add RichText

PlainText cards are for unstyled text.
Add PlainText

These cards allow unrestricted use of HTML. See the documentation on HTML cards.

Add HTML

On Wagn you upload images to Image cards, then include them wherever you want the image to appear. Learn more about Image cards.

Add Image

Uploaded files are stored with Files cards: cards whose type is "File".

 

Creating or editing a File card will prompt you with a standard upload interface.

 

security

 

Most content managers do not check permissions on file downloads; if you know the url, you can get the file.  They may try to keep the url a secret, but the internet being what it is, that's not a terribly safe approach.

 

By contrast, Wagn checks card permissions on every user's initial download of every protected file. 

 

In technical terms, most systems expose directories of uploaded files directly to the webserver, so that the application isn't involved in any way in web requests.  That makes it pretty much impossible for the application to check permissions on the files.  Wagn, on the other hand, associates every file (including every image) with a card, and the read permissions on the card are equivalent to the read permissions on the file.  Once Wagn determines that the user has permission to view the file, it hands the process back to the server (via xsendfile), and the download begins.

 

performance

 

Won't all this extra permission checking slow things down?  The primary answer is that we keep things fast by only doing these checks once.  Wagn gives unique urls to each file and image revision and instructs browsers to use cached versions of those revisions after the first download.

 

We will also soon be implementing optimizations to insure that public files (those that can be read by "Anyone") will skip permission checking altogether.

 

urls / api

Web API
/<cardname>
/<cardname>.<ext> # accepts "rev" param specify revision number /files/<card_id>/<action_id>.<ext>
Examples: GET /my_paper # returns card (html page). content is download link GET /my_paper.pdf # returns file. most recent revision. browser cannot cache GET /files/~67/12345.pdf # this is what is linked to in card content. returns file. server tells browser to cache permanently.

 

 

file storage

files/:card_id/:action_id[-:size].:extension
  • by default the files directory is in "local" before 1.13 and in the app root beginning with 1.13
  • you can configure a custom files directory in wagn.yml with "attachment_storage_dir"
  • the files should NOT be directly exposed to the webserver (eg, by putting it in the "public" directory); this would negate all the value of wagn's permission checking.
  • :size only applies to images and can be any of the following: icon, small, medium, large, original

 

special views

 

All file cards have a "source" view that will provide a standard url for the card (see the third variant above).

Add File

Most of Wagn is written in the Ruby programming language, using Ruby on Rails.

 

 

Add Ruby

Pointer+view interface
Pointer cards let you create and maintain lists of cards.

 

They are a key tool in Wagneering, for relating cards to other cards.

 

For example, let's say you are setting up a Wagn for a conference that features lots of break-out sessions, and you want to know later who went to what session. You would create a Session cardtype, and on its form you would include a Pointer, which on each Session would list the people who participated in that session. What Pointers "point" to is one or more cards (or none), so in this example it would be pointing to each participant's User card.

 

This approach has several advantages over typing people's names into a regular text card:

  • You can pick an editing interface to suit the situation (auto-complete, checkboxes, dropdown menu, etc.)
  • There's no markup required to link to or include the cards you want to list.
  • You can easily set the views of all the items in the pointer wherever you include it using the "item" property. E.g.,   Items will appear by default in closed view.
  • You can draw on the information in other places. In the example given above, you could then add to the structure of User cards a Search card to automatically list the sessions they've attended.

 

In view mode, Pointers have an "add/edit" link beneath them which you can click on to go to edit mode.

 

Pointers have several different edit interfaces, which may be set using the *input setting.

 

To continue our example from above, assume you include a Pointer called "+participants" on the Session form. In that case, you can set "Participants+*right+*input" to be any of the following input types.

 

list

Pointer+edit interface
"List" view is the default interface for Pointers. It is basically a series of autocomplete fields.

 

In list view, when you start typing an item, Wagn will do its best to fill in the rest by listing the names of existing cards that begin with whatever you typed in (much like it does in the navbox).

 

radio

A list of radio buttons, each for one card. One and only one may be selected.

 

checkbox

A list of checkboxes, each for one card. You can select as few or as many as you want.

 

select

A dropdown menu of cards.

 

multiselect

A box listing all the relevant cards and allowing any number to be selected.

 

You don't want every card in your Wagn to be listed. Even a brand new "empty" Wagn has hundreds of cards, and yours may have thousands or more! To narrow the options, you can add a *options setting which will be a Pointer (by default, but it can also be a Search) for just the cards you want listed. For example, continuing the example if you add "participants+*right+*options" as a Search card with the CQL {"type": "User"} then only User cards would be listed when editing "Making Wikis Welcome+participants".

 

Actually, in that example there might be so many users that we wouldn't want to have all of the names on screen. If so, you'd use "list" as the *input setting, which lets people type in a name. This could be any card they want (even cards that don't yet exist), but the Pointer will autofill cards that are in +*options. So in our example, this would mean that if I typed "Ja", then the pointer would autocomplete users' names beginning with "Ja".


Option labels

 

Checkboxes and radio buttons can have supplementary information next to each option. Let's say in our conference website example that we invite each person to share information about themselves on their User card in an included card called "+about me". And then we decided it would be useful to show that information on the Session card when editing our +participant Pointer. We can achieve this by creating an "participant+*option label" setting and setting its content to be "about me".

 

 

Add Pointer

A set is a card that defines a group of cards.  

 

Any given card belongs to multiple sets. For example, the card named Wiki on Wheels is a member of these three sets:

Rules are created by connecting Settings to Sets with the following formula:

Set + Setting = Rule

Each Set card offers a convenient interface for viewing and editing related Rules.  For example:

Rules

There are currently eight kinds of sets.  From broadest to narrowest, they are:

  1. All Cards: *all
  2. All Plus Cards: *all plus — (learn about plus cards)
  3. All Cards of Type X: |Type X|+*type — (learn about card types)
  4. Star Cards: *star — (learn about star cards)
  5. Cards ending in +(Star Card): *rstar
  6. Cards ending in +(Name X): |Name X|+*right
  7. (Type X) + (Name Y) Cards: |Type X|+|Name Y|+*type plus right
  8. A Single Card: |Name X|+*self

 Any rule on narrower set (higher number) will override a broader one (lower number).

 

For example, suppose you want to have a special layout for a card named "World Map".  You can set the layout for that one card with the following Rule: "World Map+*self+*layout".  Note that this connects a Set of one card ("World Map+*self") to the Setting "*layout".  This rule would overrule any broader *layout rule, such as *all+*layout, because the single card set (#8 above) is narrower than the set of all cards (#1 above).

 

Add Set

Settings (or Rule Types) are options about how a card looks and behaves.

A Rule applies a specific Setting to a specific Set of cards. For example, the *update setting governs who can update cards. So one could make a rule with that setting that says only Administrators can create HTML cards. 

See the Rule card to learn more about how to use Decko Rules.

Note: the Setting+howto video is badly out of date and thus removed from this page.  We hope to update it soon.

Add Setting

Every card has a type, which shapes what kind of information goes into it. You can also add your own cardtypes. To learn more, read the documentation about card types.

Add Cardtype
Text

Data

Upload

Custom

Organize

Template

Admin

Styling

Scripting

Some Custom Types

If you've got a question, a bug to report, or an idea for improving Decko, we warmly invite you to

add a Support Ticket!

 

If you would like more substantial support, including a support contract, please see our services page.

 

Open

Acknowledged

Pending

Answered

Can't Reproduce

Closed

Add Idea

Intro

Geek Intro

Cards

Inclusions

Types

Formatting

Cool?

Why?

Who's Using It?

Who Makes It?

What's Next?