Re: move token map from UIXCollection to corresponding renderer
thanks for checking this in for me. I filed issue http://issues.apache.org/jira/browse/ADFFACES-243 so that the renderers for UIXTree and UIXTreeTable can take advantage of this new api to prune the client-rowkey map when nodes are collapsed. at the moment this client-rowkey cache grows indefinitely (note that it grew indefinitely for these components, even before issue 210 was fixed). --arjuna On 10/16/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I made a few minor changes to this as reported on http://issues.apache.org/jira/browse/ADFFACES-210 On 10/15/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I've updated http://issues.apache.org/jira/browse/ADFFACES-210 with this discussion and a patch. let me know what you think. On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: sorry, that last method has to be public (Renderer needs access to it during encodeBegin to do pruning). so UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) public final ClientRowKeyManager getClientRowKeyManager() On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer?
Re: move token map from UIXCollection to corresponding renderer
I made a few minor changes to this as reported on http://issues.apache.org/jira/browse/ADFFACES-210 On 10/15/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I've updated http://issues.apache.org/jira/browse/ADFFACES-210 with this discussion and a patch. let me know what you think. On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: sorry, that last method has to be public (Renderer needs access to it during encodeBegin to do pruning). so UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) public final ClientRowKeyManager getClientRowKeyManager() On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
Re: move token map from UIXCollection to corresponding renderer
I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I
Re: move token map from UIXCollection to corresponding renderer
sorry, that last method has to be public (Renderer needs access to it during encodeBegin to do pruning). so UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) public final ClientRowKeyManager getClientRowKeyManager() On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string
Re: move token map from UIXCollection to corresponding renderer
YES!! (I've always found currency to be about the most confusing term imaginable.) -- Adam On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: after this is checked in, I want to start a new thread to rename UIXCollection.get/setCurrencyString to UIXCollection.get/setClientRowKey does this make sense? On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods
Re: move token map from UIXCollection to corresponding renderer
I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString (..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers
Re: move token map from UIXCollection to corresponding renderer
after this is checked in, I want to start a new thread to rename UIXCollection.get/setCurrencyString to UIXCollection.get/setClientRowKey does this make sense? On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString (..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only
Re: move token map from UIXCollection to corresponding renderer
Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString (..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or
Re: move token map from UIXCollection to corresponding renderer
I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString (..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or RowKeyStringManager, or CurrencyStringManager. The tableRenderer would implement this. The UIXCollection class would cast its renderer into an instance of this new API and use it to handle the get/setCurrencyString methods. It would be up to the renderer to prune and manage the lifecycle of these token strings. The renderer would probably store the mapping as a private attribute on the component so that it is properly serialized along with the component. What do you think? Arjuna -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: move token map from UIXCollection to corresponding renderer
http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString(..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or RowKeyStringManager, or CurrencyStringManager. The tableRenderer would implement this. The UIXCollection class would cast its renderer into an instance of this new API and use it to handle the get/setCurrencyString methods. It would be up to the renderer to prune and manage the lifecycle of these token strings. The renderer would probably store the mapping as a private attribute on the component so that it is properly serialized along with the component. What do you think? Arjuna -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: move token map from UIXCollection to corresponding renderer
What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString (..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or RowKeyStringManager, or CurrencyStringManager. The tableRenderer would implement this. The UIXCollection class would cast its renderer into an instance of this new API and use it to handle the get/setCurrencyString methods. It would be up to the renderer to prune and manage the lifecycle of these token strings. The renderer would probably store the mapping as a private attribute on the component so that it is properly serialized along with the component. What do you think? Arjuna -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: move token map from UIXCollection to corresponding renderer
sorry for the delay. Not sure if I got it completely, but your suggestion to move that stuff from UIXColl. to a Renderer API makes pretty much sense. At least from that what I understand. The customized treeTable support might be much much more important, when all of the renderer api overhauls are done. can you nail this issue into Jira? Thanks! Matthias On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString(..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or RowKeyStringManager, or CurrencyStringManager. The tableRenderer would implement this. The UIXCollection class would cast its renderer into an instance of this new API and use it to handle the get/setCurrencyString methods. It would be up to the renderer to prune and manage the lifecycle of these token strings. The renderer would probably store the mapping as a private attribute on the component so that it is properly serialized along with the component. What do you think? Arjuna -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: move token map from UIXCollection to corresponding renderer
ok, I will file a jira.
Re: move token map from UIXCollection to corresponding renderer
hi, anyone like to comment on this? feel free :) --arjuna On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Folks, Currently the UIXCollection class (which is the super class for table/tree/treeTable) maintains a mapping between Object rowkeys and String tokens. see private ValueMapObject _currencyCache = null; I would like to suggest that we move this mapping from the component and into the corresponding renderer. We would still have the methods UIXCollection.getCurrencyString() UIXCollection.setCurrencyString(..) However, these would call into the renderer and the renderer would maintain the mapping, and would control pruning of the mapping. Why should we do this? The reason is that only the renderer knows exactly which tokens are still being used on the client-side. The component does not know this. And so the component does not know when to clear or prune this mapping. At the moment the component is clearing the mapping at the start of each encode cycle. But this breaks some 3rd party renderers which are still displaying certain rows on the client-side. A good example is the treeTable component. Let's say the tree is rendering a certain set of rows. The tokens for these rows are being held in the mapping. Now the user expands a node, introducing a new subset of rows. Tokens for these rows are now needed (in addition to the existing tokens). The encode phase starts and the mapping is cleared. The current trinidad treeTable renderer rerenders the entire tree, so all tokens (including the ones for the newly inserted rows are recreated) and things work fine. Now let's suppose a 3rd party treeTable renderer has an optimization that only rerenders the part that was inserted. Since the component cleared the mapping, only the tokens for the newly inserted rows will exist. The tokens for the old set of rows (which still exist) on the client-side are missing. Things will break during decode when the treeTable is subsequently submitted. Suggested Changes Introduce a new Renderer API called , for eg: RowKeyTokenManager, or RowKeyStringManager, or CurrencyStringManager. The tableRenderer would implement this. The UIXCollection class would cast its renderer into an instance of this new API and use it to handle the get/setCurrencyString methods. It would be up to the renderer to prune and manage the lifecycle of these token strings. The renderer would probably store the mapping as a private attribute on the component so that it is properly serialized along with the component. What do you think? Arjuna
