How is this different from just setting the current row index to -1?
On Tue, May 6, 2014 at 1:49 PM, Jing Wu <[email protected]> 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 >>> >>> >
