incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arjuna Wijeyekoon" <arj...@gmail.com>
Subject Re: move token map from UIXCollection to corresponding renderer
Date Tue, 10 Oct 2006 01:22:59 GMT
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 <arjuna@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 <arjuna@gmail.com>
wrote:
> > > > > > > > > > > Folks,
> > > > > > > > > > >
> > > > > > > > > > > Currently the UIXCollection class (which
is the super
> > > class
> > > > > > > for
> > > > > > > > > > > table/tree/treeTable) maintains a mapping
between
> > > > > > > > > > > Object rowkeys and String tokens.
> > > > > > > > > > >
> > > > > > > > > > > > see
> > > > > > > > > > > >     private ValueMap<Object>
_currencyCache = null;
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > I would like to suggest that we move
this mapping from
> > the
> > > > > > > component
> > > > > > > > > > and
> > > > > > > > > > > into the corresponding renderer.
> > > > > > > > > > > We would still have the methods
> > > > > > > > > > > UIXCollection.getCurrencyString()
> > > > > > > > > > > UIXCollection.setCurrencyString (..)
> > > > > > > > > > >
> > > > > > > > > > > However, these would call into the
renderer and the
> > > renderer
> > > > > > > would
> > > > > > > > > > maintain
> > > > > > > > > > > the mapping, and would control pruning
of the mapping.
> > > > > > > > > > >
> > > > > > > > > > > Why should we do this?
> > > > > > > > > > >
> > > > > > > > > > > The reason is that only the renderer
knows exactly
> > which
> > > > > > > tokens are
> > > > > > > > > > still
> > > > > > > > > > > being used on the client-side. The
component does not
> > know
> > > > > > > this.
> > > > > > > > > > > And so the component does not know
when to clear or
> > prune
> > > > > > > this
> > > > > > > > > > mapping.
> > > > > > > > > > > At the moment the component is clearing
the mapping at
> > the
> > > > > > > start of
> > > > > > > > > > each
> > > > > > > > > > > encode cycle.
> > > > > > > > > > > But this breaks some 3rd party renderers
which are
> > still
> > > > > > > displaying
> > > > > > > > > > certain
> > > > > > > > > > > rows on the client-side.
> > > > > > > > > > >
> > > > > > > > > > > A good example is the treeTable component.
Let's say
> > the
> > > > > > > tree is
> > > > > > > > > > rendering a
> > > > > > > > > > > certain set of rows. The tokens for
these rows are
> > being
> > > > > > > held in the
> > > > > > > > > > > mapping.
> > > > > > > > > > > Now the user expands a node, introducing
a new subset
> > of
> > > > > > > rows.
> > > > > > > > Tokens
> > > > > > > > > > for
> > > > > > > > > > > these rows are now needed (in addition
to the existing
> > > > > > > tokens).
> > > > > > > > > > > The encode phase starts and the mapping
is cleared.
> > > > > > > > > > > The current trinidad treeTable renderer
rerenders the
> > > entire
> > > > > > > tree,
> > > > > > > > so
> > > > > > > > > > all
> > > > > > > > > > > tokens (including the ones for the
newly inserted rows
> > are
> > > > > > > > recreated)
> > > > > > > > > > and
> > > > > > > > > > > things work fine.
> > > > > > > > > > >
> > > > > > > > > > > Now let's suppose a 3rd party treeTable
renderer has
> > an
> > > > > > > optimization
> > > > > > > > > > that
> > > > > > > > > > > only rerenders the part that was inserted.
> > > > > > > > > > > Since the component cleared the mapping,
only the
> > tokens
> > > for
> > > > > > > the
> > > > > > > > newly
> > > > > > > > > >
> > > > > > > > > > > inserted rows will exist. The tokens
for the old set
> > of
> > > rows
> > > > > > > (which
> > > > > > > > > > still
> > > > > > > > > > > exist) on the client-side
> > > > > > > > > > > are missing. Things will break during
decode when the
> > > > > > > treeTable is
> > > > > > > > > > > subsequently submitted.
> > > > > > > > > > >
> > > > > > > > > > > Suggested Changes
> > > > > > > > > > >
> > > > > > > > > > > Introduce a new Renderer API called
, for eg:
> > > > > > > RowKeyTokenManager, or
> > > > > > > > > > > RowKeyStringManager, or CurrencyStringManager.
> > > > > > > > > > > The tableRenderer would implement this.
> > > > > > > > > > > The UIXCollection class would cast
its renderer into
> > an
> > > > > > > instance of
> > > > > > > > > > this new
> > > > > > > > > > > API and use it to handle the
> > > > > > > > > > > get/setCurrencyString  methods.
> > > > > > > > > > >
> > > > > > > > > > > It would be up to the renderer to prune
and manage the
> > > > > > > lifecycle of
> > > > > > > > > > these
> > > > > > > > > > > token strings.
> > > > > > > > > > > The renderer would probably store the
mapping as a
> > private
> > > > > > > attribute
> > > > > > > > > > on the
> > > > > > > > > > > component so that it is properly serialized
along with
> > the
> > > > > > > > component.
> > > > > > > > > > >
> > > > > > > > > > > What do you think?
> > > > > > > > > > > Arjuna
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Matthias Wessendorf
> > > > > > > > > > http://tinyurl.com/fmywh
> > > > > > > > > >
> > > > > > > > > > further stuff:
> > > > > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message