Idea

Let's say that all of our existing settings are "Type-A" Settings, meaning that they can apply to any set,

And that *account, *sol, etc, are Type-B settings (trait settings), in that they can only be used in rules that apply to single cards (*self sets).

My original interpretation was that Type-A rules would *HAVE* to have the +*self (for consistency), whereas the TYPE-B ones would either

(1) always use +*self, too, or

(2) never use +*self.

I hadn't been thinking that it would be an alias thing. In fact, until we actually have aliases, I think this is a bad idea -- it means we might have conflicting rules.

  --Ethan McCutchen.....2012-10-29 03:10:13 +0000

If they really are aliases, then there would only be one rule referred to by both cardnames, only one actual card. But I think just replacing is the way to go, the alias was more of a backup if we found that we needed the old form in some cases to avoid some ambiguity.

  --Gerry Gleason.....2012-10-29 09:23:59 +0000

I'd rather have just one pattern for *self unless we find out it creates problems for us. Just the trait-style pattern. And I'm listening for arguments that it has to be another way.

  --Gerry Gleason.....2012-10-29 09:25:33 +0000

Note that it isn't Type A and Type B, but one type with a search path through the patterns. So their could be other types if we found them useful.

  --Gerry Gleason.....2012-10-29 09:26:39 +0000

Issue 1: need an API to add codenames (migration API, that is). Foundations of the pack API too.

Loading:

We want these to load as gems in the lib/** paths and just add them to the load paths and autoload them with core packs. We would have them in overlayed trees according to standard ruby/rails pathnames/modulenames.

Example (starting proposed structure to be tweaked and extended as we go):

lib/wagn/... => lib/cards or lib/pack, something like that, but for now, I'm taking Wagn:: as our top level namespace. I don't think we should also have lib/packs by the time we release this.

Under Card, or Wagn or ...:

.../model/X for Card module included modules

.../set/ (self, type, etc.)/

.../type/set_module.rb (was set.rb)

.../type/set_view (was packs/type/set_pack.rb

.../type/set_event.rb (new for events, etc.)

Migrations:

Codenames: declare codenames as part of the "cards loaded" for the module:

Creating cards should be similar/related to import/export cards functionality, let's just use ruby source code with equivalent JSON serializations for storing and trading with other systems and the UI:

{ cards : [ name : '*set path', codename : :name (optionally that would do the to_key and strip ^* that we do in the codename migration when we don't have a current codename for it, or just 'set_path' to do it straight), type : :pointer, content : '*self' ], [] ...

}

Issue 2: need to add the path setting: codename : 'search_path', name: '*search path'

We will need a bunch of new controlling cards (rules) to set this up.

  --Gerry Gleason.....2012-10-29 17:49:37 +0000

Path for the cards to load/unload with the pack:

..../set/type/set_pack.rb (to be loaded to check the pack installation and do any (un)loading/(un)binding/migration, support for these parts will be in rake tasks in our namespace)

  --Gerry Gleason.....2012-10-29 18:11:41 +0000

A set card has a certain appearance (and gives you access to configure that set). The current options tab is a thin wrapper around the self set. If we get rid of *self, how do we see that set?

  --Ethan McCutchen.....2012-10-29 18:29:40 +0000

"Note that it isn't Type A and Type B, but one type with a search path through the patterns" That's the design approach that I'm suggesting may be overgeneralization. I'm not sure we want multiple, or that we want any of this to be card configurable.

  --Ethan McCutchen.....2012-10-29 18:30:38 +0000

I lean towards more card configurability, even if we limit how or when they can change them. Could be read-only and not even normally viewable if necessary.

And I think the comment on sets is correct and an important area to fix/refactor with this of subsequent tickets.

  --Gerry Gleason.....2012-10-29 19:03:31 +0000

I changed my mind about this solution and updated the +solution card above. Coding will be going down this new path now.

  --Gerry Gleason.....2012-11-20 14:09:53 +0000

In effect, adding a trait will add a new search item to all(some?) rule, module and view lookups. We need to be careful because some functions will apply to the +card itself.

  --Gerry Gleason.....2012-11-20 14:13:30 +0000