incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: move token map from UIXCollection to corresponding renderer
Date Sun, 01 Oct 2006 17:56:58 GMT
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