To Edit or Not To Edit

Wbmstrmjb posted on Monday, September 15, 2008

I have a scenario which we are internally debating as to the best approach to handle it.  We have a need for a list of records where the first record in the list can be "voided" (set a bit to true) in order to no longer be valid.  Every other item in the list will have been previously voided.  All of the items are read-only except for the one that may be voided.

Is it better to have a read-only list of editable items and "disable" the save for items that aren't the most current, or is it better to have a read-only list of read only items that pass the ID of the one to void to a command object that voids the record?

Ex:

ID   Name            Date         Void

4     Can Void      9/1/08      Void(Link)

2      Older           8/25/08     Voided

1      Oldest         7/12/08      Voided

JoeFallon1 replied on Monday, September 15, 2008

While a Read Only list can contain items which can be edited. I prefer to think of the list itself and the objects in it as Read Only.

So I vote for #2 - keep the ROC as purely read only and pass the value of the one to be invalidated to a command object.

Joe

 

djjlewis replied on Monday, September 15, 2008

I definitely agree it could be argued both ways. Perhaps from a purist, OO, "behaviour not data" etc point of view, then by definition the list (or at least one object) is editable because you can change its state from not-void to void. In that case, I guess the other objects would in effect have a business rule that prevents them from being saved, while the top-most object does not.

However, from a pragmatic view it may be easier and more maintainable to go with the ROC / command object approach and I do have a tendancy to go with pragmatism if it results in simplfying things...

Dan.