ScratchList or some such thing

[Ken Orr]

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

[Rob Eden]

A FreezableList in between, maybe?

Rob

On May 18, 2009, at 9:57 AM, Ken Orr <ken.orr@...> wrote:

>
> 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: 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@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Kevin Day-7]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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 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
Sent from the GlazedLists - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...

[James Lemieux]

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@...> 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@...

To: users@...

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

Sent from the GlazedLists - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...

[Ken Orr]

Sounds like the right solution...thanks James. My objects are immutable, so I think that fits in nicely with the way TransactionList works.

Thanks!
-Ken

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 <[e-mail]> 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 <[e-mail]> <[e-mail]>
> *To:* [e-mail]
> *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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: [e-mail] For
> additional commands, e-mail: [e-mail]