Re: ScratchList or some such thing

James Lemieux wrote:

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

On Mon, May 18, 2009 at 9:03 AM, Kevin Day <kevin@trumpetinc.com> wrote:

>  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@mathworks.com> <ken.orr@mathworks.com>
> *To:* users@glazedlists.dev.java.net
> *Cc:*
> *Date:* Mon, 18 May 2009 07:57:19 -0700 (PDT)
> *Subject: ScratchList or some such thing*
>
>
> 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
> --
> View this message in context: h
> ttp://www.nabble.com/ScratchList-or-some-such-thing-tp23596977p23596977.html<http://www.nabble.com/ScratchList-or-some-such-thing-tp23596977p23596977.html>
> Sent from the GlazedLists - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glazedlists.dev.java.net
> For additional commands, e-mail: users-help@glazedlists.dev.java.net
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@glazedlists.dev.java.net For
> additional commands, e-mail: users-help@glazedlists.dev.java.net