[jira] Commented: (ADFFACES-210) move rowKey string token map from UIXCollection into corresponding Renderer

["Arjuna Wijeyekoon (JIRA)" <ad...@incubator.apache.org>]

    [ http://issues.apache.org/jira/browse/ADFFACES-210?page=comments#action_12442444 ] 
            
Arjuna Wijeyekoon commented on ADFFACES-210:
--------------------------------------------

ok, so here's what I did.
I added two new interfaces:
ClientRowKeyManager and
ClientRowKeyManagerFactory.

The renderer implements ClientRowKeyManagerFactory, which has one method;
  /**
   * Create a new ClientRowKeyManager for the given UIComponent
   */
  public ClientRowKeyManager createClientRowKeyManager(
    FacesContext context, 
    UIComponent component);

This allows each renderer to provide its own ClientRowKeyManager to the component

The ClientRowKeyManager interface has the following:
  /**
   * Gets a string version of a key that identifies the row with the given rowkey. 
   * This string key can be used on the client-side to identify the row.
   * If a string key for the given rowkey does not exist, then a new one is
   * created. The lifespan of this string rowkey is entirely upto each
   * implementation. Implementors must ensure that if a particular row is still
   * present on the client-side, then its string key must also continue to be valid.
   * @param rowKey the rowkey to convert into a client key. Note that
   * null is special and is not allowed.
   */
  public String getClientRowKey(FacesContext context, UIComponent component, Object rowKey);

  /**
   * Gets the corresponding server-side rowkey object from the given client-side string
   * key. If the string key has expired, implementors should return null. However,
   * if any part of a row is still present on the client-side, its corresponding
   * string-key may not expire.
   * @param clientRowKey the string key
   * @return null, if the string key has expired, or never existed.
   */
  public Object getRowKey(FacesContext context, UIComponent component, String clientRowKey);

So this allows the RowKeyManager (and hence the renderer) to decide how to encode each rowkey.
UIXCollection has a method on it so that the renderer can access the ClientRowKeyManager instance:
  public final ClientRowKeyManager getClientRowKeyManager()

The reason we have both
ClientRowKeyManager and
ClientRowKeyManagerFactory is that
the former has to be Serializable and the component manages it internally so that the component can be used as a stamp
inside a stamping container (this is the nested table example).

The reason the render must use the public getClientRowKeyManager method (on UIXCollection) to get at the manager
(even though it was the Renderer who created the manager in the first place) is that in the stamping case, the renderer
needs access to the correct instance of the manager and only the component knows what this instance is.

So to summarize, the
renderer manages the lifecycle of the client rowkey strings via the ClientRowKeyManager class, 
and the UIXCollection component manages the lifecycle of the ClientRowKeyManager instance itself.


> move rowKey string token map from UIXCollection into corresponding Renderer
> ---------------------------------------------------------------------------
>
>                 Key: ADFFACES-210
>                 URL: http://issues.apache.org/jira/browse/ADFFACES-210
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>            Reporter: Arjuna Wijeyekoon
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira