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
