You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jing Wu <ji...@oracle.com> on 2014/05/06 00:26:13 UTC
[Trinidad] New API addition for Trinidad's UIXCollection
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
Re: [Trinidad] New API addition for Trinidad's UIXCollection
Posted by Blake Sullivan <bl...@oracle.com>.
It should be the same.
— Blake Sullivan
On May 15, 2014, at 7:58 AM, Andrew Robinson <an...@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 <ji...@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
>
>
>
Re: [Trinidad] New API addition for Trinidad's UIXCollection
Posted by Andrew Robinson <an...@gmail.com>.
How is this different from just setting the current row index to -1?
On Tue, May 6, 2014 at 1:49 PM, Jing Wu <ji...@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
>>>
>>>
>
Re: [Trinidad] New API addition for Trinidad's UIXCollection
Posted by Jing Wu <ji...@oracle.com>.
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
>>
Re: [Trinidad] New API addition for Trinidad's UIXCollection
Posted by Blake Sullivan <bl...@oracle.com>.
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
>