Author action, XSLTOperation, (insert) action: "replace": efficiency et al.

[whyme]

This might fall in the category of "sorry, but find another way." And I realize this falls across both "Common Problems" and "Feature Requests."

I have a relatively straightforward Author action based upon XSLTOperation. The (insert) action argument is "Replace" (i.e., specifies that the targetLocation should be replaced). The action works very quickly in a sample document I use for testing and development. But when I apply the action to the master document, on an element that has 9000 sibling elements, the same operation takes several minutes. I infer, from the lengthy processing time, that "Replace" somehow requires evaluating the context element's parent and therefore all its children nodes (the siblings of the context).

Sometimes I can revise the XSLT so that it produces a reduced but similar output that can be inserted inside as the last child. When I change the (insert) action argument to "Inside as last child" the operation is as fast as on the master document on the sample. It means I sometimes have to do some workarounds. But at least the operation is extremely fast in very lengthy documents. I've since learned to avoid the "Replace" option.

But now I can't. I now have to write an author action where processing must be done on only some of the context element's children. For several reasons I want to write my own .jar API only as a very last resort.

Would it be possible to make the "Replace" action more efficient so it doesn't require handling anything other than the context element?

If not, would it be possible to have for XSLTOperation a new (insert) action item, "Replace content"? Provided, of course, that is as efficient as "Inside as last child". That would bring a lot of benefits.

If not, could there be a new standard action/operation, WrapChildrenNodesOperation. This would allow someone to put all the contents of an element in a wrapper element, process that wrapper through an XSLTOperation, and then replace the wrapper, without having to touch the larger document context. (I assume.)

If not, could there be a new standard action/operation, DeleteNodesOperation. That would be similar to DeleteElementsOperation, but apply to any XML nodes, not just elements. For both the proposed and the current action/operation it would be nice to have an extra Argument about where the cursor should be placed after the operation is done. I'm trying to figure out how to get the cursor back to its original position after the application of a DeleteElementsOperation, and sure wish I could set "Preserve" on a missing "caretPosition"!

Thanks for all you do. Oxygen is the greatest piece of software I've ever used.

[adrian_sorop]

Hi,

The operation probably takes a long time because parent element's (the one with the 9000 children) layout needs to be recomputed when you replace one of its children.

If you're comfortable with XQuery, you could try the XQueryUpdate Operation. Using this, you could change only the content of nodes.
https://www.oxygenxml.com/doc/versions/ ... eoperation

The other option is to create a JsOperation and change content from the API, without adding .jar to your framework.
https://www.oxygenxml.com/doc/versions/ ... soperation

For the other suggestions (the preserve caret position, replace content action type, etc), I've logged internal issues.

Let me know if you need help with,
Adrian S.

[Radu]

Hi,

Question for the original poster, about this remark:

The operation probably takes a long time because parent element's (the one with the 9000 children) layout needs to be recomputed when you replace one of its children.

If you insert a new child element inside that parent element with 9000 children (using content completion for example) does it take about the same time as it takes to run an XSLTOperation which replaces one of the existing child elements?

Regards,
Radu