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 >
