xinclude path on paste

Thanks Clay, but that's not quite the issue. I can get the contents of the paste buffer, but by the time it is there, I can't tell where it came from. Say I have three documents open, target, source 1, and source 2. If I copy the xinclude from source 1, I can change the current doc to source 2 and even make a selection in source 2 without copying. I then shift my focus to target and paste (should be from default buffer). I can intercept the paste callback and manipulate the contents of the paste buffer. However, because I don't know if it came from source 1, source 2, or even target, the relative path in the xinclude that makes up the contents of the paste buffer in unknown, so I can't modify it to be a correct relative path when it is inserted into target.

Core Arbortext must understand this, but I can't figure out how they know the source of the paste buffer in order to change the relative path to an absolute path to the fragment pointed to by the xinclude. Does that make sense?

Steve

Hey Steve,

Sorry I'm a little slow to respond. I see in the intervening time it took to compose this response, the thread here has progressed a little further. I'll continue here with a response to your first post anyway.

Unfortunately, I can't point you to the underlying alias or function that Arbortext is using to paste an xinclude. We had need to locate that code point back 4-5 years ago when addressing a concern similar to yours and were not able to find it. At that time, we grew to suspect the key code was not within ACL code but was instead located somewhere, such as within a dll, where it was inaccessible for customization.

Our experiences in this area may not perfectly address your situation, but hopefully providing you with insights from our similar need for cut/copy/paste customizations may prove helpful.

Our needs are similar in that our xinclude references are encoded with a logical file ID which is resolved to a physical file dynamically based on the environment under which the reference is being made. And our references were being changed to physical file path references over the course of cut/copy/paste operations by default editor behavior.

Detailed view of our solution:

• 
  
• Cut and copy hooks:
  
  
  • 
    
  • These need to ensure that if the area to be cut (including that for a drag for drag and drop) or copied contains any expanded includes within it,
    that they are collapsed before the paste buffer is primed to avoid the includes href value from being clobbered back to a file system path.
  • 
    
  • As part of that collapse action, if any of the includes to be collapsed have changed content, a document save needs to be performed to properly save the includes. This involves running through the document nodes within the selected content to locate any include references.
  • 
    
  • Also, as part of potential collapse actions, one needs to take care to preserve the marked area correctly.
    
    
    • 
      
    • For this, we first use the selection_start and selection_end functions to get the oid + offset locations of the start and end of the marked area. These actually record positions within the XML stream that are just outside the selected content.
    • 
      
    • Then, to record the end of the selection in a way which will be valid after any include collapsing, we calculate the offset backwards to the end of the selection from the end of the selection end oid we acquired earlier. That gives us a way of getting back to the correct end point of the selection even if expanded includes within the selection end up being collapsed. Note that any include collapsing we may do may invalidate the selection end position we acquired first because that end position may be counting positions from an oid in front of the selection and therefore counting through elements from an expanded include within the marked area which will no longer be there after the include is collapsed.
    • 
      
  • 
    
• 
  
• Paste and include_path hooks:
  
  • 
    
  • In the paste hook, we set a global variable in effect over the course of the paste command to indicate a paste is in process.
    FYI, the bullet below contains a comment from our ACL paste hook code which attempts to explain why we resolved ourselves to having to follow an approach of collapsing includes within content to be pasted.
    
    • 
      
    • 3/12/10 - Beetcher: This note is just for future reference.
      Initially under XIS 3.0.0 (and epic 5.3) a symptom arose where, over the course of a
      cut/paste operation, the SAS XIS fileid href value within include references contained in
      pasted material was reverted to a native or relative file system path to the reference.
      A fair amount of debug seemed to pin down the point of this reversion occurring to some
      internal processing of arbortext in handling the paste operation immediately below.
      That is, when the paste buffer contents were displayed even after the paste they showed
      the href to still have the SAS ID value, but the pasted content within the target file
      ended up with the reverted href value, and all that without our ID resolution being
      activated during the paste processing.
      
      The scenario where this reversion action was somehow occurring was determined to be that where
      the paste buffer contents included both the expanded an unexpanded include material. The fix of
      we finally settled on, for XIS 5.0, was that of first collapsing included content within the a marked area before
      it ever arrived in a paste buffer. So, that's why we now perform a collapse action on includes
      within a marked area as part of our "cut" and "copy" hook processing.
      
      
    • 
      
  • 
    
  • That variable is then checked by our include_path hook to determine when an include path is being processed during a paste operation. If it is, we suppress resolution to the include's path by returning a -1 value.
  • 
    
• 
  

Hopefully, you'll find some of these insights useful for your case.

Bob Beetcher

In Reply to Steve Cuzner:

This is a follow-on to a post from yesterday. My core problem is that I need all my xinlcude file references to be relative paths from the including document to the referneced include file. If I have an xinclude in file 1 that has a relative path to an include file and I copy or cut the xinclude, then paste it into file 2, the Arbortext is transforming the relative path to an absolute path for the pasted reference.

I've used the paste callback to intercept the paste, but when I examine the paste buffer the raw markup with the relative path is there. The source of the paste buffer is not available to the paste callback, so I can't construct the proper relative path and do my own insert and cancel the default paste.

I already have a custom version of the create_include alias that ensures that my paths are relative when an inclusion is created from a selection, but this alias isn't called by the paste operation of an already existing xinclude.

Can anyone point me to the underlying alias or function that Arbortext is using to paste an xinclud so that I can override it with a custom function? Is there another callback or hook that I can use to sucessfully insert a paste buffer that contains an xinclude?

Steve