Ticket
Now that we almost have the User model connected through cards in account_cards pull request., it is time to make these controllers into card functions.
This should be the right time to add events, which should be exactly what we need for this problem.
Replace all special action handlers in controllers with event handlers declared on the base CRUD actions and maybe a few special Wagn core events as well.
Cool! Let's spell out the api in detail here for each method.
Admin Controller
/admin/setup
Hrmm. add a :setup card? GET it for the form, PUT (or POST?) to it for the setup? params should follow pattern of signup (below)
√ /admin/show_cache
Easy one. Just add a :cache view. Eg. /my_card?view=cache
/admin/clear_cache
I'm thinking we add a :cache card. Content is overview of cache usage (for whole site, unlike show_cache above, which is for a single card).
Then to clear the cache, maybe DELETE /:cache? As with session, this isn't an actual deletion...
/admin/tasks
# already deprecated. only real todo here is to migrate away old links where possible.
Account Controller
/account/signin
POST (or PUT?) to :session card
(POST makes more conceptual sense, as we're creating a session, but PUT may make more practical sense, since PUT statements expect an existing card. Same goes for admin/setup)
/account/signout
DELETE /:session
√ /account/signup
GET /:account_request?view=new
POST (new account request card)
/account/forgot_password
GET /(account card)+(:password)?view=edit
PUT /(account card)+(:password)
# custom events to generate new password or verification code or whatever
√ /account/invite
GET /:user?view=new
POST (user card)
√/account/accept
√/card/update_account
PUT /(account card)
# needs some param design
√/card/create_account
POST (new account card)
/card/rollback
/card/watch
√ /card/comment
/card/save_draft
will work on these soon...
CardController#create_account is handled by an event handler on CardController#create. This handler would do the former create_account action for a set: Self::CreateAccount on the :create event.
Similar for CardController#update_account, likely a PUT request to the same resource.
AccountController#signin would be a Set::Self::Session#create action, and it would do signin, that is bind the account card to the web-session. Signout out DELETE /:session (name *session or *user or ...)
This is really exciting.
note, I will want to update all the forms to match the new, simplified pattern. happy to work on that...
--Ethan McCutchen.....2012-12-06 20:54:23 +0000
We need events for this too, but I think that should have it's own Ideas/Issue card, right?
--Gerry Gleason.....2012-12-10 11:09:07 +0000
yes, I will bang on that.
--Ethan McCutchen.....2012-12-10 16:21:34 +0000
I think that Invite and Signup are both POST :create, :id=>'*account', and Accept is like update_account, PUT :id=>'UserName', :account=>{:status=>'active'}
--Gerry Gleason.....2012-12-12 03:50:26 +0000
1. invite and signup (in their current version), both have GET versions. what is design for those?
2. why would it be to create '*account'? There are actual cards getting created, and *account isn't one of them. Shouldn't the POST just have the details of the actual cards?
Suppose we're signing up "Barry". If we need to create Barry, Barry+*email, Barry+*account, then the question is just what the params look like, no?
--Ethan McCutchen.....2012-12-12 04:42:01 +0000
it probably makes sense at this point to get very clear on how we really want the nested cards api to look. do we like the cards thing? also, do we like this notion of having all the POST details under card? eg card[name], card[type_id], etc
--Ethan McCutchen.....2012-12-12 04:44:08 +0000
GET /*account+*invite and /*account+*signup, and they POST could post back there are to *account card
--Gerry Gleason.....2012-12-12 19:23:52 +0000
the GET /*account can still work as it does currently
--Gerry Gleason.....2012-12-12 19:25:16 +0000
I agree about nested cards. I think it should be thought of as POST/PUT with a payload that is multiple cards updated together. At some point we make these groupings significant for change notifications
--Gerry Gleason.....2012-12-12 19:26:32 +0000
I will be converting existing rails views at this point. I think this is the solution outline for signup/invite.
The link (account_links): if Card[:account].ok?(:create, :trait=>:invite); :edit view of *account+*invite, but POST's to *account else Same view *account+signup
Then the forms are in cards.
--Gerry Gleason.....2012-12-13 10:45:22 +0000
cool, I think we can do this with a simple branch off of develop, right?
please look into the #fieldset method in renderer. This will help make it so all fields look uniform throughout the site.
my impulse would be to do GET /:signup, GET /:signin, and GET /:invite for the forms (very simple API)
I'm still not clear about whether, in general, we want the root card variables to be (eg) card[name], name, model[name]? I kind of think we should standardize. My impulse is to break them up into param groups like model=>{}, event=>{}, and view=>{}. We don't necessarily have to implement all of that right away, but I think it's time to have a plan.
--Ethan McCutchen.....2012-12-13 18:49:26 +0000
Yeah, signup/invite are simple and good ones to start with.
--Gerry Gleason.....2012-12-13 20:07:29 +0000
Ok, so we jus t said that it isn't just GET, but a :new view (GET still, but different view)
I'm going to attempt an implementation: add codenames for :signup, :invite and :forgot_password and give them all :new views on a self-pattern. I'm not sure about accept yet, so I'll work on the others first.
I don't think we want codenames for those, do we?
Not yet, but I would be adding them. Or rather some do and some don't.
I've been playing around with what seems to work best, and the direction I'm going is to make at least the new account request, (invite and signup) just have the input form described by a structure rule on cardtype. I think that is better than custom views, but it also means that the cards codenamed :invite and :account_request would need to be type Cardtype so you can make the account_links view link to /new/AccountRequest and /new/*invite. Currently, both of these actions (create a request from either signup or invite links) create AccountRequest cards, so I think I would fix that up in an event for the invite case.
What I noticed just now is that results in the form having '+*account+*email' on the left in the form, which seems bad from a UI perspective, but I'm not sure we can override that now (or can we).
Account Request is already a cardtype. Invite should probably not be one.
This needs to be designed with a lot of top-down thinking. Folks are going to come in and want to choose how new users are created. Do you get how that works now? How *invite and *request and *signup currently hack a bunch of that together? It's really pretty awful, so now's the great opportunity to fix it.
Please don't implement until we agree on a card structure design. If this ticket is too broad, we can create a narrower one to discuss that. There's a whole rhythm of propose / hone / agree / implement that should generally happen when we're working on stuff that involves changes to user experience. We need to make sure all this stuff gets in +solution cards on tickets, not tucked away in discussions or skype chats.