be consistent about text, non-text, and formatted cards

Your question helps me realize i'm assuming one direction of something that could go two ways. Every card in Wagn has text content in the database. There are several ways we see the card by default (mostly ignoring view for now):

We see its content, lightly interpreted if at all (raw/edit views; Number, Basic/PlainText/Phrase, Date).
We see its content, heavily interpreted / rendered / executed (HTML, Ruby, Script). When we edit, we see the "source".
We see an object referenced (Image, File). The content encodes this in some way.
We see a virtual object (it's controlled by a content form).

From when i have contemplated "everything is a ___" systems well before Wagn, i remember at least once thinking it would be good to have a 'basic' (i probably thought 'wiki' :-) text field even on objects which have non-textish content. But somehow early on i came to think of Wagn cards as going the other way, with each card *either* having textish content, *or* some fancier thing going on — file, image, being templated, etc. So when the content from the database has been revealed, i have seen it as a bug, as non-Wagn structure showing up and breaking the intended model.

Now that i'm clear on all that, i'm pretty unattached either way. I do think we should be logically consistent one way or the other. Either we develop toward ways to make the text field accessible and useable for fancier cards, or we hide it away like it doesn't exist. As we approach modules, our clarity about this will set the tone for people developing new cardtypes.

--John Abbe.....Wed May 05 07:40:35 -0700 2010

(I restored this from an autosave just to make sure we didn't lose what you've already written. If you've still got this in progress and see a conflict when you save, just overwrite me!)

--Ethan McCutchen.....Wed May 05 10:23:15 -0700 2010

Thx!

--John Abbe.....Mon May 10 02:04:01 -0700 2010