Design+API

leverage rails api
   1. basic operations should be same as standard rails models:  create, destroy, updates through attribute accessors.
       this helps coders learn the api and helps the models integrate with standard usage at the controller level.  
  2. access to underlying operations should be retained, ie: create_without_wagn
  3. flow of error checking/validation, callbacks, & database updates should follow/integrate with rails as much as possible.

cardegories (types)
cardegories are classes in ruby under the card namespace, ie.  Card::Number, Card::Person.  Cardegories have a standard class
hierarchy, and are all stored in the cards table via the rails STI mechanism.  'Virtual' cardegories can be created by users through
the interface, and ruby classes are generated on the fly.  The cardegory table for a wagn is the authoritative list of available cardegories for that wagn--
even if a ruby class exists in the code, it must have an entry in the cardegory table to be available for use.

question: do we want to change the 'type' field to 'cardegory' and tell rails to use that as the STI field? 

update tracking
for standard active records, setting an attribute is very lightweight, and the validation and database updates
are always the same regardless of what attributes have been set.

for wagn cards, several of the attributes require a lot of additional work; setting a name or permission can trigger cascading changes to lots of other cards-- we don't
want to do that work unless we know the attribute has been changed-- this will require an update tracking mechanism;  afaik there's no way with
a standard active-record to tell whether an attribute has been changed from it's db value or not without querying the database.  An update tracking
system could also be useful for logging-- it allows you to set multiple attributes at once, and have the logger record the ones that actually changed.

I'm thinking  @card.updates would be an object holding the updates per field, sort of like @card.errors holds errors per field.
a class method could be used to add tracking to a given field:

class Card
   tracks :name, :reader, :writer, :content
   ...


update options
Some attribute changes require additional behavior specification, such as specifying whether to update links when renaming.  This is the only thing that
could throw into question the model of using standard attribute assignment-- if the api is  @[card.name][http://card.name] = 'newname',  where/how do you tell it whether to
update links or not. 

One way to handle this is just have additional attributes to specify those behaviors.  @card.on_name_change_update _links = true
This fits in well with the standard update_attributes() mechanism, which in turn should work well with standard CRUD usage in controllers.

@card.update_attributes( :name=>'new-name', :on_name_change_update_links= >true )

if this is the way we go, we should come up with a standard naming scheme:
on_$field_change_$option
when_$field_updated_$option
...

update tracking part 2:  save()
complex operations like rename or permission changes don't happen when attributes are assigned, but as part of the save process-
during save, @ card.updates is examined and necessary changes (rename, permission change, cardtype change, etc.) are executed.

1. validation- as far as possible without making changes, we validate that the updates are allowed and will work-- if not, we add to record.errors and
bail out just like regular validations-- this includes checking permissions
2. the database changes for all the updates are performed inside a single transaction.