Pattern Cards+implementation+discussion

I'm not sure I fully understand the patterns proposal, but I was trying to explore the code use cases.  At first I was thinking that you would just go from a card, which matches a set of patterns, each of which can have a set of attribute values (Lewis suggested thes are the plus cards of the pattern, but I'm not sure if this is best.

What I imagine instead is the patterns connected with a card as a set of resources available to configure the operation of each hook defined by the application.

• Permissions - card controller before filters are declared in a DSL where controller actions (:view, :edit ...) are mapped to an auth category (:read, :write, :comment, :create, :new_cardtype, whatever I need for my app).  Now we would call card(self).patterns(:perm => auth_category) which would? Iterate through the patterns matching {|pat| path.action(:perm)(card, arg (which gets auth_category bound to the :perm action)).  Someplace :perm is defined in a DSL that can access any of the patterns matching the card to find related cards with the roles and auth_categories allowed or denied for the card.  The DSL also defines the return conditions (:allowed, :denieed, or :ok, :deny, :signin ?)
• Cardtype - someplace we need to declare that <card>+*Cardtype (or whatever the standard will be) is the cardtype card.  Even if it stays in the cards table, this part should be explicite and configureable via patterns.
• content-type - I think that the idea of a raw, or primitive cardtype needs to be moved to the  content as a "content-type" field that is part of each revision alongside the data (content).  I think this will also be central to the API to add primative cardtypes.  If a content-type module can handle some foreign content-types on input, they can import from that version on editto automatically convert.  If it can't the old content type is still there in the revision history.
• templates - this is the most prolific part of the proto-pattern stuff in wagn.  I'd like to see how you expect that to work in the patterns version.  I think this is a lot like the permissions case where we need a DSL that identifies any existing related template cards based on the patterns, and decides which apply based on view, action, content-type and any other attribute available to the DSL.

--- Gerry

I came to this by thinking about what the code that uses all this would look like and where it would be situated. Below is an attempt to psuedo code a card controller:

class CardController << ApplicationController

before_filter :action_ok

def action_ok

auth = action2auth(action)

patterns { |pat| pat.permissions(self,auth) }

end

end

# posting with just the permission part so far ...

  --Gerry Gleason.....Sun Oct 11 14:09:09 -0700 2009