From adffaces-dev-return-1365-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 09 23:32:03 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 68050 invoked from network); 9 Oct 2006 23:32:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Oct 2006 23:32:03 -0000 Received: (qmail 98097 invoked by uid 500); 9 Oct 2006 23:32:02 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 98070 invoked by uid 500); 9 Oct 2006 23:32:02 -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 98056 invoked by uid 99); 9 Oct 2006 23:32:02 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 16:32:02 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of arjuna@gmail.com designates 66.249.82.231 as permitted sender) Received: from [66.249.82.231] (HELO wx-out-0506.google.com) (66.249.82.231) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 16:32:01 -0700 Received: by wx-out-0506.google.com with SMTP id s13so1858590wxc for ; Mon, 09 Oct 2006 16:31:40 -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=UX3387v3iq9Ys8xweGgd7YiFLkxa2+Jp5CctpR5RNnR/r860oVuVW+sJhnLk6gl9imEQIgzLVwLHl6zYSvIm1l9rto31HeNQzqXb08dTrZ59IwqtmLs2myD/7+XxH34sqSO+iJEyu8XhqZwrJArKZOYqP+7fDLgiEH0fZ1xzeiA= Received: by 10.90.72.10 with SMTP id u10mr3305814aga; Mon, 09 Oct 2006 16:31:40 -0700 (PDT) Received: by 10.90.119.1 with HTTP; Mon, 9 Oct 2006 16:31:40 -0700 (PDT) Message-ID: <75e54f200610091631u1dfda5dfme9dd266605fa6530@mail.gmail.com> Date: Mon, 9 Oct 2006 16:31:40 -0700 From: "Arjuna Wijeyekoon" To: adffaces-dev@incubator.apache.org Subject: Re: move token map from UIXCollection to corresponding renderer In-Reply-To: <6dac79b90610072302g452e9d44q9c7b756356aa710f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_227444_32372370.1160436700329" References: <75e54f200609221155l43c0d29ete28a285f6436ec96@mail.gmail.com> <71235db40609260229u722661deoe2836b8954fc964b@mail.gmail.com> <75e54f200609291203x5b3a6dfhfdfce507610f1b34@mail.gmail.com> <75e54f200609291210u291d120bi4ed7a010c996e9e7@mail.gmail.com> <6dac79b90610011056m540ad6f0ne6c069742506495b@mail.gmail.com> <75e54f200610041446p7e833aa8t3d8883b4e69baa08@mail.gmail.com> <75e54f200610041556y6b80a704lccf1727343822d8c@mail.gmail.com> <75e54f200610071832u21b96b03ubc55e290fca4ac5e@mail.gmail.com> <75e54f200610071845m6e5ac9bfn2d7ae32ade3841fd@mail.gmail.com> <6dac79b90610072302g452e9d44q9c7b756356aa710f@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_227444_32372370.1160436700329 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 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 < arjuna@gmail.com> 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 < awiner@gmail.com> 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 < arjuna@gmail.com> 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 < arjuna@gmail.com> 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_227444_32372370.1160436700329--