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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] > wrote:
> > > > > > > > >
> > > > > > > > > http://issues.apache.org/jira/browse/ADFFACES-210
> > > > > > > > >
> > > > > > > > > On 9/26/06, Matthias Wessendorf < [EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > 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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
