Solution

We propose to abstract the idea of a "pattern" out from these separate problems -- conceptually, in card structure, and in code.  The basic idea is that we should be able, whenever applying a behavior (edit cues, formatting, etc) to cards following a given pattern, to specify that pattern precisely and independently -- that is, without having to bind, say, editing behaviors to permissioning behaviors.

Let's start by looking at the common case we have now where we want to talk about all the cards of a certain type, say "User".  Currently we'd just attach things to the User card itself, as with User+*tform and User+*edit.  These two examples illustrate two subpar solutions to the same problem with our current system: poor pattern identification.  With *tform we choose to identify the pattern in the star card, which means we've had to create *tform and *rform.  To push this solution further, we'd have to create more and more star cards to support more patterns.  The *edit solution is really avoidance.  It doesn't differentiate, so there is no way to change *edit cues for User cards without also changing it for cards ending in +User.

The simplest solution we've found is to have a card that identifies each pattern separately: one card that represents all the user cards, and another card that identifies all the cards ending in +user.  Conveniently enough, we already have those cards!

User+*type cards is a search that finds all cards of type user.  Whether that's the ideal nomenclature is debatable but not the point.  The point is that a search defines the pattern.  In essence, it is the pattern.   Once you have the pattern, you can attach the pattern-shaping star card to that pattern card (the search card).  So, for example, formatting for all User cards might be set on User+*type cards+*form  (instead of User+*tform), and editing cues for all those cards might be set using User+*type cards+*edit.  And now we've solved the problem of what to name *edit and *new instructions that are only meant to apply to user cards --> eg. User+*type cards+*edit

Benefits

What does that get us?  First, it allows us to apply patterned behavior to a lot more things.  Among our current star cards, good candidates for patterns include form cards (*tform, *rform, which may become just *form or *format), *edit, *new, *table of contents, *options, *watchers.  We can build patterned layouts, including expanded definitions of things like *sidebar, *logo, *favicon, etc. And, perhaps most importantly, we can set up patterned permissions (see separate section below).

Second, we can create a much richer and more nuanced array of patterns.  Currently we have a primitive form of support for a few proto-patterns:  "type", "card+name", and "type+type"  (not sure whether "type+name" is actually working?).  Now, we add a vast array of WQL-able patterns.

That said, though all patterns are searches, not all searches can be patterns, at least initially.  A search including a "match" operator, for example, would not be "patternable", because as explored in the implementation section below, it is important that we not only be able to start with a pattern and find all the cards that conform to it (which basically means running the WQL query) -- we must also be able to start with a card and find all the patterns to which it conforms.  The match operator complicates this.

For starters, there will probably a limited ok-set (a white list) of patternable WQL operators and properties.  These are very likely to include type, name, right, and left.  The initial list may not be much larger than that but may grow as the pattern mechanism matures. 

Special Cases

We will also need a clear mechanism for searching for "self" patterns that allow us to make isolated settings on a single card.

On the other extreme, we will also likely wanted a *all or *default card that is used to set site defaults.

And we'll definitely want a "star card" pattern, one way or another.

Will be helpful to look at "initial permissions" page -- we'll certainly need to represent all those patterns for our permissions.

Overlapping Patterns

Many cards will meet multiple patterns.  If, for example George+wishes is a Basic card, and there are pattern cards for both Basic cards and cards ending in +wishes, which pattern will it follow?

The first point to make is that most patterns won't have all settings.  Just because there is a Basic card pattern does not mean that there is a *form setting for Basic cards.  For there to be a conflict to resolve, there must be multiple setting values.  So it's a setting conflict, not a pattern conflict per se.  But let's assume that we have a setting conflict.  How do we choose?

Our current solution is Pattern Precedence.  How exactly to represent this precedence is not yet spec'd, but the idea is that all patterns on a given Wagn can be ranked from weakest to strongest.  Something like *all or *default will be the weakest (though likely most prevalent) pattern on a Wagn, whereas the narrower patterns will generally be "stronger" (though less prevalent), in that they take precedent.

So our current example, George+wishes, may actually conform to 3 patterns: *all, Basic cards, and cards ending in +wishes (all 3 of which would be represented with searches), which for now we'll call A, B, and C.  Lets say we'd ranked them from weakest to strongest in that same order (A, B, C).    Then, if there were a *edit setting card for the +wishes pattern, that's the card that would apply -- it's the strongest pattern.  If not, then a *edit setting card for Basic cards would rule.  Lacking that, it goes to *all.

Here are some things to consider when spec'ing our pattern precedence:

1. we don't want to have to fiddle with precedence every time we create a pattern.  we should usually be able to get away with some default behavior (probably rules out a pointer rep)
2. we would like to have certain patterns firmly planted at the weak and the strong extreme.  *all should be built-in to be very weak.  *itself (or *self or *alone or whatever) should be built-in to be the strongest pattern, overriding everything else.
3. eventually we'd love to have a simple, probably drag and drop GUI for resorting pattern precedence

This likely means that precedence is done via a search that sorts first by assigned precedence (probably a plus card on a pattern) and second by some implicit, constant indicator (like id or create date, both of which should generally yield the same order except in cases of specially imported data).