move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

hi,
anyone like to comment on this? feel free  :)
--arjuna

On 9/22/06, Arjuna Wijeyekoon <ar...@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
>
>
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

thanks for checking this in for me.
I filed issue
http://issues.apache.org/jira/browse/ADFFACES-243

so that the renderers for UIXTree and UIXTreeTable can take advantage of
this new api to prune the client-rowkey map when nodes are collapsed.  at
the moment this client-rowkey cache grows indefinitely (note that it grew
indefinitely for these components, even before issue 210 was fixed).
--arjuna

On 10/16/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> I made a few minor changes to this as reported on
> http://issues.apache.org/jira/browse/ADFFACES-210
>
> On 10/15/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > I've updated
> > http://issues.apache.org/jira/browse/ADFFACES-210
> >
> > with this discussion and a patch.
> > let me know what you think.
> >
> > On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > >
> > > sorry, that last method has to be public (Renderer needs access to it
> > > during encodeBegin to do pruning).
> > > so UIXCollection has:
> > > public String getClientRowKey()
> > > public void setClientRowKey(String clientKey)
> > > public final ClientRowKeyManager getClientRowKeyManager()
> > >
> > >
> > >
> > > On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > > >
> > > > 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 <ar...@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
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

I made a few minor changes to this as reported on
http://issues.apache.org/jira/browse/ADFFACES-210

On 10/15/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> I've updated
> http://issues.apache.org/jira/browse/ADFFACES-210
>
> with this discussion and a patch.
> let me know what you think.
>
> On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > sorry, that last method has to be public (Renderer needs access to it
> > during encodeBegin to do pruning).
> > so UIXCollection has:
> > public String getClientRowKey()
> > public void setClientRowKey(String clientKey)
> > public final ClientRowKeyManager getClientRowKeyManager()
> >
> >
> >
> > On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > >
> > > 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 <ar...@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
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

I've updated
http://issues.apache.org/jira/browse/ADFFACES-210

with this discussion and a patch.
let me know what you think.

On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> sorry, that last method has to be public (Renderer needs access to it
> during encodeBegin to do pruning).
> so UIXCollection has:
> public String getClientRowKey()
> public void setClientRowKey(String clientKey)
> public final ClientRowKeyManager getClientRowKeyManager()
>
>
>
> On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > 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 <ar...@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
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

sorry, that last method has to be public (Renderer needs access to it during
encodeBegin to do pruning).
so UIXCollection has:
public String getClientRowKey()
public void setClientRowKey(String clientKey)
public final ClientRowKeyManager getClientRowKeyManager()



On 10/9/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> 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 <ar...@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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <ar...@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 <ar...@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 <ar...@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
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
>

Re: move token map from UIXCollection to corresponding renderer

[Adam Winer <aw...@gmail.com>]

YES!!!!!!

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

-- Adam


On 10/7/06, Arjuna Wijeyekoon <ar...@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 <ar...@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 <ar...@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 <ar...@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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <ar...@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 <ar...@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 <ar...@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
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <ar...@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 <ar...@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 <ar...@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
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <ar...@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 <aw...@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 <ar...@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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <aw...@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 <ar...@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 <ar...@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 <ar...@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
> > > >
> > >
> > >
> >
> >
>
>

Re: move token map from UIXCollection to corresponding renderer

[Adam Winer <aw...@gmail.com>]

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 <ar...@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 <ar...@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 <ar...@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
> > >
> >
> >
>
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

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 <ar...@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 <ar...@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
> >
>
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

http://issues.apache.org/jira/browse/ADFFACES-210

On 9/26/06, Matthias Wessendorf <ma...@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 <ar...@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
>

Re: move token map from UIXCollection to corresponding renderer

[Arjuna Wijeyekoon <ar...@gmail.com>]

ok, I will file a jira.

Re: move token map from UIXCollection to corresponding renderer

[Matthias Wessendorf <ma...@apache.org>]

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 <ar...@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