incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arjuna Wijeyekoon" <arj...@gmail.com>
Subject Re: move token map from UIXCollection to corresponding renderer
Date Wed, 04 Oct 2006 21:46:49 GMT
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 <arjuna@gmail.com> 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
> > > >
> > >
> > >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message