From adffaces-dev-return-1277-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Sun Oct 01 17:57:07 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 98611 invoked from network); 1 Oct 2006 17:57:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Oct 2006 17:57:06 -0000 Received: (qmail 74304 invoked by uid 500); 1 Oct 2006 17:57:06 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 74287 invoked by uid 500); 1 Oct 2006 17:57:06 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 74278 invoked by uid 99); 1 Oct 2006 17:57:06 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Oct 2006 10:57:06 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=awiner@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from [66.249.92.168] ([66.249.92.168:39230] helo=ug-out-1314.google.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 15/41-05102-D6100254 for ; Sun, 01 Oct 2006 10:57:03 -0700 Received: by ug-out-1314.google.com with SMTP id y2so536421uge for ; Sun, 01 Oct 2006 10:56:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ECVsHgk+XfrniFJKVKRiR/jLuDhP75rZ+RrD4vKd0Lq0I4n6+z9FNdQzvBkA5ZCaQ4jsBxKpJwyxy6al2ROEWG5GCeixfSiLo9gbh6Lu+NIyXWc0RNXuyogSWfIraDtPznP0Oyx8T7RN+oowcGPxnxQS8y5yP8cp3ZrffWroXmE= Received: by 10.67.100.12 with SMTP id c12mr2112170ugm; Sun, 01 Oct 2006 10:56:58 -0700 (PDT) Received: by 10.67.99.17 with HTTP; Sun, 1 Oct 2006 10:56:58 -0700 (PDT) Message-ID: <6dac79b90610011056m540ad6f0ne6c069742506495b@mail.gmail.com> Date: Sun, 1 Oct 2006 10:56:58 -0700 From: "Adam Winer" To: adffaces-dev@incubator.apache.org Subject: Re: move token map from UIXCollection to corresponding renderer In-Reply-To: <75e54f200609291210u291d120bi4ed7a010c996e9e7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3732_13315456.1159725418339" References: <75e54f200609221155l43c0d29ete28a285f6436ec96@mail.gmail.com> <71235db40609260229u722661deoe2836b8954fc964b@mail.gmail.com> <75e54f200609291203x5b3a6dfhfdfce507610f1b34@mail.gmail.com> <75e54f200609291210u291d120bi4ed7a010c996e9e7@mail.gmail.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_3732_13315456.1159725418339 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 wrote: > > > > http://issues.apache.org/jira/browse/ADFFACES-210 > > > > On 9/26/06, Matthias Wessendorf < matzew@apache.org> 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 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 _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 > > > > > > > > > ------=_Part_3732_13315456.1159725418339--