-
Notifications
You must be signed in to change notification settings - Fork 1.7k
ModelManager#addPerson(ReadOnlyPerson) should not update filtered list #648
Comments
@yamgent issue validation tq ^^ |
Yes, I think the fact that filtered list should change when a person is added should not be known to the model. |
I am going to make a wild guess that the intention of the original developer was that, if the user filtered the list, and the new person happens to fit the query used in the last If we are updating this method to not update the filtered list, then some other classes will have to handle that (and if possible, handle the corner case that I have mentioned in the first paragraph too). |
|
The "corner case" meant the scenario when your list is actually filtered (and not showing all person), so the ideal action shouldn't even be to reset the list to show all, but only to add on to the filtered list such that the new person is shown, without making other persons (that was hidden by a previous 'find') visible again. Anyway this seems to be another case of "the filtered list shouldn't be in the model" problem. In an ideal situation, commands shouldn't even be responsible for updating something that is more related to the UI. |
Ah I get what you are saying now. @damithc what are your thoughts on Wang Leng's comment that "the ideal action shouldn't even be to reset the list to show all, but only to add on to the filtered list such that the new person is shown, without making other persons (that was hidden by a previous 'find') visible again."?
Yup, seems like it :P |
Yes it's better not to reset the filtered list view when adding a new person, as long as there is good feedback to reassure user the person added is exactly as the user intended. One benefit of resetting the filtered list is that the new person is guaranteed to be in the new list and and the user can visually confirm the person is added correctly. |
The text was updated successfully, but these errors were encountered: