sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

Pattern Cards+implementation

help edit space_dashboard

+overview

help edit space_dashboard

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.

 

 

+module outline

help edit space_dashboard


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?

 

 

 

 

help edit space_dashboard

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