Information Classification: External Restricted.
See https://www.chili-publish.com/security

Copying XML content between documents

The basic concept and usage can be similar to ?Updating or duplicating XML content vs. completely creating content. But in addition, it can also apply to ?Inserting new top-level resources. And on top of that, you might in fact want to copy/move even more complex content: all (or a subset of) frames on a page, or a complete page item.

The complexity in this operation lies in all referenced objects. Such as (just on the Frame object) layer, fillColor, borderColor, fontFamily, alternateLayout, imageVariable, and much much more.

So when inserting the new XML, you will need to device a way to:

  • Find out which resources from the source document are in fact used in the XML portion you're trying to copy
  • Find out whether or not a similar resource already exists in the target document
  • Figure out a strategy for inserting the new resources (or potentially overwriting/updating) the existing resources in the target document
  • Update the references to the relevant resources in the XML portion you're trying to copy
  • Insert the new XML into the target document

Some of the proposed solutions may seem "quick and dirty", but they are in fact running in production in quite a few locations where customers have performed custom development around CHILI

Find out which resources are used

You can, for example:

  • Loop through all top-level resource sub-nodes of the "document" root element of the source document
  • For each resource, figure out the type of possible references, and see if they are used in the XML portion you're trying to copy:
    • For any of the resources, you can (and should) check on its ID, between double quotes. This will match instances like layer="123-456-789", variable="569-123-234", and so on. The use of GUIDs as IDs within CHILI documents makes it HIGHLY unlikely that this will provide false positives
    • Fonts: see ?Fonts XML. These are referenced using family + "_" + style. So one way of finding the referenced fonts (mostly in TextFLow and ITextLayoutFormat objects) would be to search for that value in the XML portion (as a string), surrounded by double quotes. This would match the font being referenced as fontFamily="FAMILY_STYLE"
    • Variables: see ?Variables XML. Next to matching IDs, to be completely correct, you should:
      • Find all variable text frames (isVariable="true")
      • Parse their "textFlow" property into an XML document (keep in mind that a TextFlow object contains an xml namespace)
      • Search for %VARIABLE_NAME% in the innerText of that XML document (to also match exceptions such as <p><span>%VARIA</span><span fontSize="10">BLE_NAME</span></p>

NOTE: this should be an iterative process. Once you find a "used resource", that in turn may contain other references, to other resources (eg: a frame might have fillColor "MY_Gradient". That color, in turn, might reference otherwise unused colors in its item node, specifically: gradientColor1 and gradientColor2).

The end result of this first step is that you have a list (per top-level resource) of IDs or objects or item nodes (preferably) which are used throughout your XML portion.

Find similar resources in the target document

Next up, you will need to identify whether or not each of those found resources from the source document might conflict with resources in the target document. Examples of such conflicts are:

  • "System" resources, with different IDs (eg: color "[Black]", paragraphStyle ?"[None]", ...). These are easy to handle: in your new XML portion: replace all instances of the source item's ID with the target item's ID
  • IDs which are the same between the two documents. This might happen if you have started both documents from the same source (by copying the entire document, for example)
  • Item names which are the same between the two documents. Most lists assume unique names (colors, variables, layers, alternateLayouts, ...)

NOTE: colors where isDocumentColor="false" should not be considered as a conflict, as they should only apply to a single object. If a conflict appears to arise for those, you can simply insert the source color into the target document with a new ID (and updating the reference to the custom color accordingly)

Inserting or updating the used resources in the target document

Here the really tricky part starts (at least: on your end, thinking-wise). What will you do if a conflict occurs. You have a few options, but they totally depend on your own workflow. For example: both the source and the target document contain a used color with the name "MAIN_COLOR". You can follow a number of strategies:

  • Replace all references in your XML portion to point to the target document's MAIN_COLOR. So: the color value of the target document is preserved
  • Update the XML of the color in the target document to match the values in the source document (and still update references in the portion XML, of course). So: the color value of the source document is preserved
  • Create a new color in the target document (eg "MAIN_COLOR (2)"), with the values of the color of the source document. So: two colors exist in the new document, all frames and other objects keep the same color, but the purpose of the Color List might have been broken
  • Throw an error in your code, or present the user with a choice in your code (potentially a different choice not only for each top-level resource, but maybe even for each individual item)

The chosen strategy might differ for various top-level resources.

Updating the references in the XML portion

All of the above have given you:

  • A list of used resources
  • A list of conflicts, and their resolution
  • The possibility to traverse those lists, and update the target document + replace all references in your portion XML (using a similar procedure as followed when finding used resources)

Insert the new XML portion into the target document

If you made it this far, you'll manage

All information on this page must be treated as External Restricted, or more strict. https://www.chili-publish.com/security