Confirmed users
503
edits
Calendar:Architecture: Difference between revisions
→comments from mvl
| Line 210: | Line 210: | ||
2: excessive cloning. | 2: excessive cloning. The idea of a commit sounds like a good one. But the need for a new interface and a way to detect the changes feels a bit complicated and fragile to me. We could change the model somewhat by not committing to a calendar, but having a commit method on the item itself. Thiw would work like this: Each item has a number of setters, like for the title. Calling this setter will write the new value in some shadow variable. It won't be stored directly in the item. You need to call commit first. Then the item will tell it's calendar about the change. | ||
(This part needs some more thought, ideas are welcome) | |||