SaintGimp
commented
13 years ago I'm doing a sizable refactoring to pull logic out of the controllers and to move behavior from the participant controller to the retreat controller (since it owns registrations). If anyone's interested they can follow along in my fork.
I've been thinking that we have some domain modeling issues around registrations, and our inpromptu design review with Corey Haines this afternoon plus my work on editing participants tonight confirmed it.
Currently we have a controller for retreats, and a controller for participants, but no controller specifically for registrations. This leads to wonky stuff like ParticipantController.AssignToRetreatChooseBedCode where we're trying to shoehorn registration stuff (i.e. choosing a bed code) into a place where it doesn't belong.
Tonight I implemented ParticipantController.Edit and was feeling pretty good about myself until I realized that it just edits the participant and doesn't allow you to edit the bed code for a retreat. Doh.
I'm not sure exactly what it ought to look like but somehow we need to more clearly express the idea that the user can take actions on retreats (add, edit, remove), take actions on participants (add, edit, remove), and take actions on retreat registrations (register the participant for a retreat, change the participant's bed code, and remove the participant's registration). It's a little bit complicated by the fact that some of those actions should be combined in the UI (i.e. create a participant, register the participant, and assign a bed code should be one screen). Until we fix this the code is going to get more and more gnarly.