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 ValueMap<Object> _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 > > > > > > > > > > > > > > > >
