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 Sun, 08 Oct 2006 01:45:09 GMT
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