Idea
+issues
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.
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.
(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.
I think this could related to solving access to attachment attributes needed to implement support enclosures in feeds too. Food for thought.
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.
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.
thanks for articulating this. I wonder if this is a meta api for generating set modules?
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.
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.
+discussed in support tickets
+relevant user stories