Page 1 of 1

getTextContent returning text in oxy_delete processing instructions

Posted: Mon Jan 14, 2013 5:49 pm
by neon096
As part of an operation we get the text from a node to perform a Search on our document repository so the user can mark up a link. The problem we are having is that we are now using track changes to hold the content the user is deleting so we can easily review the changes. When we use the AuthorNode.getTextContent() the content that has been deleted (shown below) is being used as part of the search.

Code: Select all


<link type="publication" uuid="xxx">
<?oxy_delete author="neon096" timestamp="20130114T134637+0000" content="Enter link title"?>
<?oxy_insert_start author="neon096" timestamp="20130114T134637+0000"?>Dangerous Dogs<?oxy_insert_end?> </link>
Is there a different call to only get the displayable content that would ignore the oxy_delete? Or do we have to build the content ourselves by getting a list of nodes and filtering out the ones we aren't interested in.

Re: getTextContent returning text in oxy_delete processing instructions

Posted: Tue Jan 15, 2013 10:10 am
by Radu
Hi Neil,

When the Author internal model is built, all the content (even the one marked as inserted or deleted) is present in it. In this internal model there are no oxy_insert and oxy_delete instructions, there are just insert and delete highlights.
Only when the internal model gets serialized to XML, the content highlighted as deleted is placed inside oxy_delete instructions.
Is there a different call to only get the displayable content that would ignore the oxy_delete?
Yes, there is. You can use:

Code: Select all

ro.sync.ecss.extensions.api.AuthorDocumentController.createDocumentFragment(AuthorNode, true)
The AuthorDocumentFragment is no longer connected in any way to the document from which it has been created.

If an AuthorDocumentFragment is created when change tracking is ON, its contents contains the entire content accepted (with the delete highlighted content rejected).
When the fragment is created with change tracking OFF, the deleted content is present in its content but you can use the method:

ro.sync.ecss.extensions.api.node.AuthorDocumentFragment.getChangeHighlights()

to get the ranges of inserted and deleted highlights relative to the beginning of the fragment.

Basically for your needs you could probably do something like:

Code: Select all

    AuthorAccess authorAccess = null;
boolean toggledCT = false;
if(! authorAccess.getReviewController().isTrackingChanges()) {
//Enable change tracking, we want the created fragment to have all changes accepted in it.
authorAccess.getReviewController().toggleTrackChanges();
}
Content content = frag.getContent();
String contentAsTextWithChangeTrackingAccepted = content.getString(0, content.getLength()).replace(
//The content could contain also special marker characters
//See Javadoc of AuthorDocumentFragment for more detail.s
"\0", " ");

if(toggledCT) {
//And set it back to the original value
authorAccess.getReviewController().toggleTrackChanges();
}
Regards,
Radu

Re: getTextContent returning text in oxy_delete processing instructions

Posted: Tue Jan 15, 2013 10:32 am
by neon096
Thanks Radu,

After I posted this I noticed another way to do it which seems to work.

Code: Select all


final StringBuilder builder = new StringBuilder();
final TextContentIterator iterator = access.getDocumentController().getTextContentIterator(node.getStartOffset(), node.getEndOffset());
while (iterator.hasNext()) {
final TextContext context = iterator.next();
switch (context.getEditableState()) {
case TextContext.NOT_EDITABLE_IN_DELETE_CHANGE_TRACKING:
break;
default:
builder.append(context.getText());
break;
}

Re: getTextContent returning text in oxy_delete processing instructions

Posted: Tue Jan 15, 2013 11:07 am
by Radu
Hi Neil,

Sorry, forgot about that approach. Funny because I added that API myself about a year ago in version 13.
I think you should just continue iterating (instead of breaking) when you encounter a deleted highlight, maybe after it you will find some more content after it.

Regards,
Radu