[
https://issues.apache.org/jira/browse/TRINIDAD-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803542#action_12803542
]
Mathias Walter commented on TRINIDAD-699:
-----------------------------------------
It would be great for 1.2.x too.
> tr:table to provide the ability to partially render rows
> --------------------------------------------------------
>
> Key: TRINIDAD-699
> URL: https://issues.apache.org/jira/browse/TRINIDAD-699
> Project: MyFaces Trinidad
> Issue Type: Wish
> Components: Components
> Affects Versions: 1.0.2-core
> Reporter: Andrew Robinson
> Priority: Minor
>
> It doesn't appear to me that tr:table allows for partial rendering of its
> rows. With DHTML functionality integrated with the client Trinidad AJAX code
> and the design of the CollectionModel, it should be possible to do.
> This could be very beneficial for add a new row, delete selected rows type of
> functionality. This is in a way a "diff-ing" algorithm.
> Architecture could be something like this:
> During rendering, the table can save the rendered row keys into a property to
> be saved into the component state using
> org.apache.myfaces.trinidad.model.RowKeySet
> During a partial rendering, check to see if it is possible to write a diff:
> 1) the table has been included in the list of partial targets
> 2) no parent component of the table has been included in the list of partial
> targets (a full rendering would be needed for this)
> 3) no component value changes have been to the table (this is probably the
> hard part of this - but should be able to be done using the FacesBean)
> Inside the rendering, if the above are true:
> Loop through each data model row (still needs to be done to render any
> components that have changed inside the columns), calling encode
> If the row key is new, send the row down (encode)
> Remember each row rendered
> At the end of rendering, gather the information and send instructions to the
> client:
> for each new row key, send down the row key that was rendered directly after
> that row.
> for each row key that wasn't rendered this time, send a ID to the client that
> it should be deleted.
> In the client, loop through all the IDs to delete, and use:
> var element = document.getElementById('[rowID]');
> if (element) { element.parentNode.removeChild(element); }
> for each new row (you will need access to the AJAX DOM object):
> var tbody = // code should be able to get this, knowing the clientID of the
> data table
> var newElement = TODO // get from AJAX API;
> var beforeElement = document.getElementById('[afterRowId]');
> if (beforeElement) {
> tbody.insertBefore(newElement, beforeElement);
> } else {
> tbody.appendChild(newElement);
> }
> This isn't required, but could be a nice performance enhancement, especially
> for large tables. Having the API in the AJAX layer to do this would be great
> for all complex iteration controls (tables, tree, treetables, etc). I have
> not seen a component library do this yet, but I think it would be very useful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
