Active Cards Models

Idea

+priority
Tickets By Priority  

Low priority tickets

+tag
expand_more Design
Whereas traditional web development stumbles whenever data structures emerge that weren't envisaged at the onset of the project, Decko embraces the idea that structures will ...
expand_more Core Subclasses for Card

Idea

       
...

 

+issue

Thinking about moving the User model into cards, and that it is part of a larger pattern.  What we want is to add a class, probably a Card subclass, that defines a group of specific "attributes" as "the contents of plus cards.

 

+solution

Maybe something like this:

class User < Card
  card_defaults :type=>Card::Phrase
  card_attribute :email, :status, :crypted_password, :salt, :password_reset_code
  card_attribute :invite_sender, :type => Card::PointerID
  inherited_attribute :email, :status

  # then expect to be able to use AR methods as if these are regular AR attributes
  attr_accessor :password, :name

  validates :email, :presence=>true, :if=>:email_required?,
    :uniqueness => { :scope   => :login                                      },
    :format     => { :with    => /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i },
    :length     => { :maximum => 100                                         }
    :id, :presence=>true, :confirmation=>true, :if=>:password_required?,
    :length => { :within => 5..40 }
  validates :password_confirmation, :presence=>true, :if=>:password_required?


  before_validation :downcase_email!
  before_save :encrypt_password
end

Connect up the new events to save these values in the contents of the plus cards.

 

 

expand_less +discussion

This is a bit half-baked, but I thought a ticket would be a good way to back it further.


Are validations going to be refactored into events too? That may simplify this since we are then tying into our triggers rather than AR callbacks.

--Gerry Gleason.....2013-06-08 16:28:30 +0000

(gcard = Card['G+*account']).email, for the simple case of direct mapping: gcard.trait(:email).send_if :content, but with the the 'scope fallback': (gcard.trait(:email) || gcard.trunk.trait(:email).send_if :content

 

I guess the deeper API question is whether we want/need to access data in the cards as if it where in AR fields, and then the opposite question of when we have a model external to Wagn, i.e. data is in AR models, not cards, do we want to use the virtual card mechanism to reference the AR attributes as if they were cards. Note that User+*account+*type_plus_right patterns could give the +*account cards a type (Account or User), then we use Account+*email+*type_plus_right patterns for virtual attributes.

 

Hope I'm not getting to convoluted here, just trying to put some of the design/API issues up front where we can think about them before doing too much coding first.

--Gerry Gleason.....2013-06-08 18:53:35 +0000

I think this could related to solving access to attachment attributes needed to implement support enclosures in feeds too. Food for thought.

--Gerry Gleason.....2013-06-08 18:55:24 +0000

I was thinking mainly of mapping Card[Gerry+*account].email to and from cards (i.e. Card[Gerry+*account+*email] and optionally by declaration Card[Gerry+*email] to/from Card[Gerry+*account].email), but maybe we want Card[BlogEntry+Attachment+*length] (and ...+*mime-type) to what are really 'virtual' plus cards that give the underlying value from the special model attributes associated with all attachement cards.

--Gerry Gleason.....2013-06-09 12:41:49 +0000

Maybe these are really two related features. One for mapping external models to cards and another for giving model access (AR inherited) to attributes in plus cards.

--Gerry Gleason.....2013-06-09 12:44:17 +0000

thanks for articulating this. I wonder if this is a meta api for generating set modules?

--Ethan McCutchen.....2013-06-10 03:05:43 +0000

I got a little clearer on this in the Core Subclasses for Card card, but basically I think we're going to run into trouble trying to do this with a subclass, because then we can't mix in methods from multiple sets at once. (see the sol / account example). I think the kind of API you're describing might still be useful, but it should be for connecting external systems, not configuring internal patterns, imo.

--Ethan McCutchen.....2013-06-10 15:26:11 +0000

Yes, I agree about this: "it should be for connecting external systems, not configuring internal patterns"

 

And I think we want to design the namespaces features to support external models.

--Gerry Gleason.....2013-11-16 17:20:16 +0000

+relevant user stories