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 Mon, 09 Oct 2006 23:31:40 GMT
I was trying to implement this, and immediately ran into the following
issue:

The new Renderer was storing the clientRowKey-ServerRowKey cache as a
private attribute on the component.
but this fails when the component is inside a stamping container (ie: nested
table case).

The rowkey cache must be considered special stamp state, so that it is
properly managed by a stamping container.

therefore, it has to be managed by the component and must be serializable.
So the renderer cannot implement the
ClientRowKeyManager interface.
Instead, the Renderer implements a ClientRowKeyManagerProducer interface.

so to summarize,
ClientRowKeyManagerProducer has a method
public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent)

ClientRowKeyManager has
public String getClientRowKey(FacesContext, UIComponent table, Object
rowKey);
public Object getRowKey(FacesContext, UIComponent table, String
clientRowKey);

and UIXCollection has:
public String getClientRowKey()
public void setClientRowKey(String clientKey)
protected final ClientRowKeyManager getClientRowKeyManager()

Let me know your thoughts and I can start on this implementation.
--arjuna


> 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