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, 08 Oct 2006 06:02:13 GMT
YES!!!!!!

(I've always found "currency" to be about the most confusing
term imaginable.)

-- Adam


On 10/7/06, Arjuna Wijeyekoon <arjuna@gmail.com> wrote:
>
> after this is checked in, I want to start a new thread to rename
> UIXCollection.get/setCurrencyString to
> UIXCollection.get/setClientRowKey
>
> does this make sense?
>
> On 10/7/06, Arjuna Wijeyekoon <arjuna@gmail.com> 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 <arjuna@gmail.com> 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 <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