Idea

I was just thinking about settings, and there is no reason not to at
least 'conceptually' replace it with *self+*content settings.

X+*self+*content would have to be handled specially.  The other sets all
resolve to a *self on that set or another one.

This may be a lot like the cardtype discussion (I.e should cardtype
'conceptually' be the *type or *cardtype setting).  The question is
whether we get anything by it in terms of elegance and generality, and
does it interfere with or help people to understand and use Wagn better.

I am imagining what Wagn would be like if almost any Ruby type can be a
Card.  The idea is that you need to be able to convert to and from a
content string  Card.content.to_TYPEKEY give the ruby object, and
type_instance.to_s (or maybe to_content) to store it in a card.

With many 'atomic' objects, I think this could work great, but maybe
collections need to be groupings of cards (pointers, searches, etc.) as
well as groupings of Objects.

Nothing here for the short term, but things to think about in defining
the API.  Even though we can't implement this immediately, we can
declare the API in a way that works now and when any Object can be a
card.  For one thing, maybe we reserve all core ruby and rails
classnames in the codename space (classname.to_key, that is).

-- gerry

I don't always follow the content of these internals tickets, but I love that they are ticketed! I'm probably not able to tag them everything they should be tagged, so if you others could that would be nice. There's a list of all current tags at Tickets by tag by name (but feel free to add others as appropriate).

  --John Abbe.....Thu Jan 20 20:51:03 -0800 2011

I'm thinking that maybe this card should be morphed into a Blueprint for Wagn Keys and Values. My recent discovery is the idea that cards are better thought of as a node or context for looking up settings rather than a bucket for content. Content is just one of the settings that can be associated with a node.

Note also that this means that card contents and not the cards themselves need to be polymorphic. Maybe the node should be the Card model and the values Card::Base and subclasses.

  --Gerry Gleason.....Wed Feb 02 13:12:26 -0800 2011

there may be some mine-able ideas here, but the structures described are obsolete. if still desired, let's start a new Idea

  --Ethan McCutchen.....2013-02-25 00:32:40 +0000