sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

help edit space_dashboard

help edit space_dashboard

1) prepare the work area - move remaining test:unit tests over to rspec;  optimize tests;  setup continuous integration;  review and minor refactoring of tests;  create a benchmark suite.

2) build the module skeleton
      - boot stage (presumably at the end of rails initialization); options for activating modules, etc.
      - simple pattern api - pattern matching for internal use:  given a pattern, does a card match?
      - hooks and views - create the DSL, using simple pattern matching, and start adding hooks to the system.

3) pattern cards - pattern cards define settings for sets of cards.  the settings will mostly be cached on individual cards, and changing a pattern card  propagates the changes to all affected cards.  I place this after modules because I think it would use the module hooks, and partly even be implemented as a module,  which could be activated/deactivated making it easy evaluate performance impact.

4) refactor madly
   - templating  --> pattern cards
   - permissions --> pattern cards
   - history --> module?  currently we store content revisions but have no log of name, type, or other changes.

One idea which would take "everything is a card" to extremes would be to store deltas as "immutable" cards.

   - caching --> make caching transparent part of Card API (no more CachedCard)

this will be easiest if content is stored natively on the card rather than in revisions, so it's loosely coupled to the history strategy

   - slot 'views'  --> modules defining views
   - remove card classes -> This one might be controversial.  Currently all Cardtypes are associated with a Ruby class.

this means for user created cardtypes we generate classes on the fly, which is a bit messy, and there issues revolving around the use of the Card::* namespace.  With the ability to specify hooks and view for particular card types, I think it's possible that we would not need card classes at all. 

 

Some alternatives:

 

- move views to after pattern cards. I think we want hooks and such in place before beginning pattern cards. The views implementation is more complex and may require more refactoring of Slot / Renderer / Context object to get the information we need.  Although impulsively I want to dive into view and hooks together, move views later is actually more aligned with some of our strategic plans and thinking up to this point.

 

- dive into modules & hooks right away and do some of the test refactoring as we go along. 

 

Also:  The refactorings in #4 are in no particular order, and we may not tackle them all immediately- this is sort of a palette of options.

 

  --Lewis Hoffman.....Fri Oct 09 07:28:18 -0700 2009

Was wondering how the 2.0 roadmap relates to the 1.2 branch. Will 1.x be on bugfix/maintanance mode until the first release ready development in this process, or do you have to build 1.3, 1.4 ... while 2.0 is developing? In other words when do you start concentrating on the 2.0 path? I imagine the preparing the ground part would be common to both of these, but beyond 2) you will have a fork in your own code even if the one is just on maintanance. Is this right?

  --Gerry Gleason.....Fri Oct 16 04:16:38 -0700 2009

There's nothing in this roadmap/plan about taking time to study the systems listed in References. It seems like that should be there.

  --Lewis Hoffman.....Fri Oct 23 10:44:05 -0700 2009