incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arjuna Wijeyekoon" <arj...@gmail.com>
Subject caching of rowkeys in the table
Date Tue, 09 May 2006 18:09:47 GMT
Hi Devs,

In order to identify which row was updated or clicked on (by the user in the
browser) we need a string row identifier. RowKeys in the framework are
Objects (UIXCollection.getRowKey() returns Object). So we need a way to go
from Object to String and back.

In the current UIXCollection class we maintain a cache between RowKeys and
string tokens.
During the encode phase, any new RowKey (that was not encountered before) is
assigned a new string token (which is just a counter). Then during the
subsequent decode phase each submitted string token is used to lookup the
corresponding RowKey so that updates are certain to happen to the correct
row.

In order to prevent this cache from growing indefinitely, we clear the cache
at the start of each encode phase.

This approach has the following problems:

   - During a ppr request, some string tokens might still be "active" on
   the browser. However, we clear the token cache at the start of the encode
   phase, so on the next submit those old tokens could conflict and cause
   errors or updates to the wrong rows.
   - Increases the size of the component-state-saving tree.
   - Sometimes the same row is displayed by different components, and
   each component has its own cache which is wasteful.
   - The string token has no "meaning" so it makes things harder to debug
   on the client-side.

Possible solution
So if we get out of the business of caching the RowKey-string map, then we
don't have to worry about being consistent with the state on the
client-side. I think we should put the burden of producing a String rowkey
on the CollectionModel implementer. The CollectionModel can have two new
methods:
public String getRowKeyAsString(Object rowkey);
public Object getRowKeyFromString(String rowkey);

The default implementation of CollectionModel can use standard java
serializing (followed by base 64 uuencode) to go between Object and String
(in the event that the RowKey is not already a String).

And the corresponding methods on UIXCollection:
getCurrencyString()
setCurrencyString(String)
will also change to
getRowKeyString()
setRowKeyString(String)

Optimization for TreeModel

TreeModel will typically create long RowKey Strings, eg:
/foo/bar
/foo/bar/baz
/foo/bar/boo

However, if the component renderer detects that the rowkey String of a child
starts with the rowkey String of the parent rowkey, then the renderer can
use this to only write the parent's rowkey string (once), and write only the
discriminating parts of each child key, eg:
/foo/bar
./baz
./boo


thoughts? Can I start on this implementation?
--arjuna

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