Multiple roundtrips for repeat controls

[frankf]

docx4j is working very well for us. Thanks!

When updating a docx file, with a repeating row, multiple times via preprocess/applybindings, the XPathIDs and XPaths of the cell contents have the "row"/etc. numbers expanded, which get longer and longer with each update via XML.

Before I dig further into it, is there a simple (or not so simple) method to, prior to the next XML update,

1. delete all the table rows except the first (to get it back to the initial template state), and

2. to set my XPathIDs and XPaths (and associated bindings/mappings) for the remaining repeat table row back to the "virgin" state during my updates, e.g., restore:

table_1_field1_0_0_0_0_0_0

to table_1_field1 as the control field's XPathID

and to restore:

/yourxml/table_1[1][1][1][1][1][1]/table_1_field1

to /yourxml/table_1/table_1_field1?

I saw references to the RemovalHandler, but am unsure if that is part of the solution.

Thanks, Frank.

[jason]

Just wondering why you are using an output docx as input into the preprocess/applybindings process?

Is there a reason why you can't start with a fresh copy of the original input docx?

[frankf]

We add the docx file to our document management system. As the document is routed through various approvals, etc., while in the document management system, we display a UI using the fields/values extracted from the docx file. The reviewer can then change values in the fields to indicate a change in "state", add new comments, etc.

The docx file is then updated with the new/revised values from the UI and routed on to the next reviewer, with additional iterations.

The original source "empty" docx file may or may not be available, or at least not to the document management system, as it may have been checked into the document management system from a client computer.

[frankf]

In looking further at this, I see where http://www.docx4java.org/trac/docx4j/changeset/1579, as one of the changes, did this: "support re-processing of OpenDoPE repeat (except 0 case)", which description seems to be exactly what I'm trying to do.

In this, it strips off the [0].. from the end of the XPath (from the last element of the XPath).

And I see where docx4j already handles #1 above (remove all table rows except the header row and the first row with control fields).

Are there plans to incorporate #2 above for both XPathID and the intermediate XPath elements (not just the last) for "support re-processing of OpenDoPE repeat (except 0 case)"?

If not, I'll look at the OpenDoPEHandler code to see if I can create a "resetTable" method to be called before OpenDoPEHandler.preprocess.

Any advice on "gotchas" when changing the XPath (remove intermediate [n]s) and renaming XPathIDs? Thanks.