On Fri, 29 Jun 2007, D John Anderson wrote:
On Jun 29, 2007, at 8:49 AM, Davor Cubranic wrote:
How about committing after the user navigated away from the *item* that
was modified, not on every attribute?
That's what I was proposing in option 1 below
Your option 1 is timed commit, so you probably mean option 2. The
difference is that you're proposing committing every time an attribute has
been changed, whereas I was proposing a save only once the user selected
another item to display, even when multiple attributes have been changed
in the DV.
But this would probably also need a timer that would commit anyways after
a minute if no further modifications were made but the user never
navigated away.
This is option 2 below
So it sounds like you prefer both options, right?
I was suggesting having the timed commit as a fallback, but commit
changes immediately if another item has been selected. Although it is
possible that this would not be worth the extra complexity.
Davor
John
Hi:
I'm working on bug #9507 which is caused by someone editing the title of
an event. These changes aren't committed as they occur for performance
reasons. I'm considering a few simple options:
1) Commit every X seconds (say 5 or 10) if there are changes that need
to to be saved
2) Commit every time the attribute editors set an attribute.
I suspect option 1 would work a little better than option 2. I was
curious to know what you guys thought.
Also, Andi, is there an API to know if there are changes to commit in
the UI view?
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
