Issue is that we have certain information, like accounts, that need to add information to cards but that (unlike rules) can only be applied to a single card (not to other sets).
Need customization so that specific Settings can apply only to *self sets.
Gerry's proposal:
Need a trait pattern, so that <foo>+<tagname> is a pattern that can be applied to any card, possibly limited by another setting to some subset of all cards.
In pattern lookups, this is a special pattern key, or rather it is patterns without a key, so there will be a global list of traits that a module can add their trait-name to. The trait name is either a special Setting card or a similar type, most likely they will all need codenames for necessary code supports. In module lookups, each trait may include methods and overrides, so the registered order will matter or we will need another config to give them a priority.
to clarify:
*account is a...trait setting?
Gerry+*account is a... trait rule?
and if we just say "trait", we mean....? Perhaps a "trait" itself is not a card, but just, well a trait. Gerry has the trait of having an account.
if there are methods and overrides, how do they fit in to the set hierarchy? What does that api look like?
Think about the newly refactored +*accounts mapping for login functions. We have the set of "Cards with accounts" and the "accountable" setting for the permission of adding a +*account card to a base card, but it is the User card that is used in Roles and for accessing a profile, etc. I think that the function that was on the "Options -> account" tab before Ethan releases his forms and menus refactor is naturally mapped to that plus card, so when I select the edit-account function from a User's card (any card with account), I'm now working with the trait card vs. the card with the trait.
I want to add a messaging system for currencies so that <a card>+*sol is the messaging trait for a card, and when a card has such a trait, I need to be able to add options to edit or post to the trait card from the base card.
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
+discussed in support tickets
+relevant user stories