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
> > >
> >
> >
>
>
