Pattern Cards+implementation

Pattern Cards+implementation+overview

Use cases

The two most common use case for patterns are:

  1. we have a card and need to know a pattern-based setting.
  2. we are executing an action on a card and need to know which pattern-based hook or view to execute

 

Approach

As patterns are implemented (pattern cards created, hooks declared, etc.), they are registered in a big hash (internal or external to ruby process depending on needs) by their pattern key.   To find the patterns for a given card, we generate a set of pattern keys for that card, and look up the patterns for each of those keys.

 

We will likely cache settings, as well as all cacheable views, on the card.  When a pattern card is changes, all effected cards have their cache updated.

 

 

Pattern Cards+implementation+module outline


On 10/13/09 6:40 AM, Gerry Gleason wrote:

On 10/12/09 6:03 PM, Lewis Hoffman wrote:

On Sat, Oct 10, 2009 at 5:47 AM, Gerry Gleason wrote:

So we would have these chunks to implement cards:

  1. Card content model (we haven't talked about this much, but I think this is where the hooks Lewis is talking about comes in. Task: catalog the content processing we do now: wiki-rendering to handle [[]] and {{}} stuff, slot based type editors, other type rendering
  2. Card naming model (the semantics of the virtual fields, name and key, + segmentation of names)
  3. Card storage model (Wagn is a flat namespace derived directly from the naming model) We have just scratched the surface in these discussions about how we might want to extend Wagn with respect to namespaces, multiple wagns refering to each others content. name resolution and scopes/contexts.
  4. Change model (i.e. how we handle revisions) -- I will come back to this along with Ethan's question about what I said earlier about revisions.
I like these broad categories. I'm a little fuzzy about Card storage being at the same level-- it seems like there's a lot of change/revision handling and content processing that we just wouldn't do if the card were actually stored on another wagn.

I agree, this is fuzzy. I'm going to address this in a separate post to keep this one shorter.

Gerry

Coming back to this as a separate topic ...

I identify this as a topic at this level, not because of all the possible technologies that might support many low level storage models, but because of the connections with namespaces and the languages (Wadl, WQL, WPL (Wagn Pattern Language) or whatever variants emerge) that are part of the card system. The reason storage models matter at this level is because of the possibility of migrating Wagn content, sets of cards from one or more shared namespaces (decks) and between these spaces. At the model level identifying a collection of cards, what I'm calling a Deck they way wagn.org Cardtype "Deck" does as the core abstract model for cards.

I want to keep the simple model of a "namespace" as a specific "deck of cards" as a building block for more complex systems. Then I can build virtual namespaces from sets of namespaces with specific storage model level relationships. In a language context, I can bring in all the ideas of contexts and binding that we have in the HLL context (Ruby and Rails here, but we want to support translation of this model to any language platform). One deck the most basic binding. in LISP they created an "a-list", which was just a list of atoms (symbols) and values, then as the language developed the basic a-list could appear in different context so implement static and dynamic binding ideas. In modern usage this is a hash object, here a hash of "name" to "card".

With these namespace/context tools avaialble to the language designer, I want to also give tools to the systems designers. Here we may be managing a knowledge base for a whole network of projects, maybe several of them are already on wagns and I have ten wagneers building cardsets as tools for all of this. And that is just one of many projects I'm working on as a systems analyst and designer. I'm using git to manage releases that are propagated to test, development and production instances. I'm also presenting users with a number of "unified" namespaces that are really the "union" of different wagns that depend on the users "subscriptions" whether automatic based on roles and groups or sign-ups.

And the "production" instances include both internal and external resources. Externally I have a whole ecosystem of Wagns and WagNets that I am deploying as well as dozens more that I connect to as resources. My flagship deployments for MetaCurrency and FlowPlace are pushing the state of the art in Wagn, and are composed of distributed cardsets served up by a network cloud of "simple" carddecks and a lot of complex machinery to move the cards and find them wherever they are distributed to.

Now do you see why I want to have something about storage models that penetrates to the core of the wagn languages?

 

 

Pattern Cards+implementation+code sketches    
module Pattern   class << self     @@store = {}          def create( spec )       matching_classes = active_classes.select {|pattern_class| pattern_class.recognize( spec ) }       raise("invalid pattern") if matching_classes.length ...

Pattern Cards+implementation+keys and classes    
 A Pattern Class is a certain kind of pattern.  eg. 
  • cards of a certain type  
  • cards with a certain name
  • card plus a
...

Pattern Cards+implementation+hooks and actions    
    on [:create,:update] (re) generate pattern keys look up applicable patterns sort patterns by precedence store cacheable settings   on :create, :type=>"Pattern" add to ...

 

Pattern Cards+implementation+older notes    
Here's the general process:
  1. Get all the patterns to which the card conforms in order of pattern precedence.  There are lots of
...

 

  • View
  • Changes
  • Options
  • Related
  • Edit
    •
    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
    Pattern Cards+implementation+discussion, Pattern Cards+implementation, Pattern Cards, implementation, discussion Gerry Gleason  

     

    try it

     

    wagneers

    intro

    videos

    features

    syntax

    weekly calls

    ideas

     

    twitter

    mailing list

     

    developers

    roadmap

    next release

    tickets

    pack API

    REST API

    one-pager

     

    github

    mailing list

     

    wagn.org

    recent

    todo