I'm wondering what more experienced developers think about how to handle almost identical processes, such as a user creating a profile and a user editing their profile. At the moment I have a single controller method and single view which handle the distinction between a new user and existing/editing user, just by passing around an $editing flag, so i know to handle any slight differences between the two. Having these conditionals throughout my controller method and view feels a little messy, but then it also feels like a lot of duplication to create a distinct view and controller method for each situation. What do people tend to do in this situation?
+1
A:
When I set up a system which can create new users, I tend to require only minimal information on registration - email and password for instance.
Then, the "profile" section of your site can then handle all the editing of the remaining user details, without having to worry about whether or not this is a new or existing user.
In my experience, people tend to get put off when registering for something if too many questions are asked right at the beginning! Delay what is not really necessary, and collect that information later!
Dave Rix
2010-06-24 23:09:01
Makes sense Dave, that's what I would normally do, but on this occasion I have a fairly long winded (and necessary) registration form. More or less all of the registration data is editable by the user once they are registered, so that's what prompted my question really - less code but with lots of conditionals, or duplicated code without the need for the conditionals!
samwatt
2010-06-24 23:18:57
Ok, so could you alter the layout of the page to collect the items that need to behave differently into one or two larger sections? Then you have fewer conditionals present, but still the same single main script.What about the back-end? Theoretically you could alter the target of the form depending on the edit/update type, or again, separate out the form processing into larger chunks based around the conditionals.Whichever you choose, sounds like you'll need plenty of comments to remind future editors to "if you edit here, you MUST also edit there"!!!:)
Dave Rix
2010-06-24 23:48:09
+2
A:
I think you should always consider the long-term aspects of design decisions.
It may be cleaner to separate these functions, but then you have two clean functions. So in terms of aesthetics you could argue either way. There is the age old trade-off between clean duplicated code and maintainabilty.
However in the long term other considerations come into play, and you start to think about risks. The risk of duplicating the code is that the two code parts become out of sync, potentially in subtle ways that are hard to detect (e.g. able to add data that is rejected on update). This can be much worse if you are not the person maintaining the code, or you have not touched the code for a long time.
So IMHO keep the editing flag. You have everything in one place, messy though it is.
Phil Wallach
2010-06-24 23:27:22
Thanks for the reply Phil - think I will keep the editing flag, especially while there are minimal differences in the processes.
samwatt
2010-06-24 23:59:57
I generally code the ORM so that the code can merrily assign information and it doesn't care if it's a new object or an existing object. When the final `save()` is called, the object itself figures out whether it does an `UPDATE` or an `INSERT`.
staticsan
2010-06-25 06:12:31
I wouldn't necessarily call the editing flag "messy" and it is much more preferable than duplicating code which - as Phil mentions - can create havoc. DRY has not been invented as a rule for the rule's sake. It is the summary of much pain felt throughout the history of software development.
Marjan Venema
2010-06-25 07:15:23