« Return to Thread: ScratchList or some such thing
Re: ScratchList or some such thing
by James Lemieux
::
Rate this Message:
Ken, the behaviour that you describe is supported by TransactionList.
You can do something like:
BasicEventList -> FilterList -> TransactionList ->...
and have TransactionList "buffer changes" while a transaction has been started by not yet commit()ed or rollback()ed. You actually have your choice of deciding whether the changes are seen downstream of TransactionList before the commit() occurs or not, and thus whether it is the commit() or rollback() operation that will be "costly." Both behaviours can be valid in different use cases so we support them both.
TransactionList is only capable of rolling back LIST-level changes, not object level changes, so rather than mutating the existing elements of your EventList IN PLACE you'd probably want to make/treat those objects as immutable and build NEW replacements when edits occur. In this way, rollback() can always perform a full rollback and truly restore your original state prior to the transaction.
Hope this helps,
James
You can do something like:
BasicEventList -> FilterList -> TransactionList ->...
and have TransactionList "buffer changes" while a transaction has been started by not yet commit()ed or rollback()ed. You actually have your choice of deciding whether the changes are seen downstream of TransactionList before the commit() occurs or not, and thus whether it is the commit() or rollback() operation that will be "costly." Both behaviours can be valid in different use cases so we support them both.
TransactionList is only capable of rolling back LIST-level changes, not object level changes, so rather than mutating the existing elements of your EventList IN PLACE you'd probably want to make/treat those objects as immutable and build NEW replacements when edits occur. In this way, rollback() can always perform a full rollback and truly restore your original state prior to the transaction.
Hope this helps,
James
On Mon, May 18, 2009 at 9:03 AM, Kevin Day <kevin@...> wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...I've been looking for something like this myself to support Apply operations for buffered user interfaces (i.e. present the user a list, allow them to make modifications, but don't make those modifications to the 'live' list pipeline until the user hits Apply or Commit).The behavior sounds suspiciously like a reverse-bahaving TransactionList - but I haven't had time to look to see how hard it would be to invert the logic to achieve the desired results...- K----------------------- Original Message -----------------------From: Ken Orr ken.orr@...To: users@...Cc:Date: Mon, 18 May 2009 07:57:19 -0700 (PDT)Subject: ScratchList or some such thingView this message in context: h ttp://www.nabble.com/ScratchList-or-some-such-thing-tp23596977p23596977.html
I have an EventList with a bunch of data relative to many files. API
consumers can ask for a pared down list that contains a list of elements
that only pertain to a particular file on disk. Here's the simple pipeline:
EventList (all data) -> FilterList (data for a given file)
My problem is this:
The consumer of that list wants to render the list contents on screen. They
also want to allow the user to edit the contents of that list without
actually committing the changes upstream yet (so the list would be in a
"dirty" state).
Is there any solution built in to GL for such a problem? Do I need a new
type of list, like a ScratchList that can be used to locally edit and then
push it's changes upstream? Am I thinking about the problem wrong?
Thanks guys!
-Ken
--
Sent from the GlazedLists - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: ScratchList or some such thing
| Free embeddable forum powered by Nabble | Forum Help |
