It should be the same. — Blake Sullivan
On May 15, 2014, at 7:58 AM, Andrew Robinson <andrew.rw.robin...@gmail.com> wrote: > How is this different from just setting the current row index to -1? > > > On Tue, May 6, 2014 at 1:49 PM, Jing Wu <jing.x...@oracle.com> wrote: > Thanks Blake for your comment! > > It's the component that is hanging onto a rowkey, the model naturally reacts > to key change and has valid state. But UIXCollection component caches the key > in it's internal state object which needs to be cleared out and recalculated. > So the proposal is to simply provide a hook for module (e.g. a listener that > listens to key change) to clear out the component's cache. So when next time > there's need to get the current key from the component, since there's no > cached value, the component will retrieve it from the model which contains > the already updated key. > > > Thanks, > Jing > > > On 5/5/2014 8:33 PM, Blake Sullivan wrote: > Jing, > > What is an example of a case where code external to the model implementation > knows that: > 1) The model is hanging onto a rowKey > 2) The key is invalid > > The model implementation is typical supposed to encapsulate this information. > > -- Blake Sullivan > > On May 5, 2014, at 3:26 PM, Jing Wu wrote: > > Hi, > > This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471. > > UIXCollection caches the current row key in its internal state. There are > cases that the row key becomes stale / invalid in the middle of processing a > row. A new API invalidateCurrentRowKey() is added to UIXCollection to clear > out the cached current row key, so next time when it is requested, this > current new key will be recalculated from model. > > > /** > * Invalidate the cached current row key so it will be recalculated > * from the model next time when it is requested. > */ > public void invalidateCurrentRowKey() > { > } > > Any comment is welcome! > > Thanks, > Jing > > >
