As we were working on one of the feature, I came across a scenario.
If I am setting 3(a,b,c) out of 4 properties (a,b,c,d) of a document, then
EXIM API clears the property value for d. (Image in my case)
Based on some previous conversations, I had an idea that it doesn’t override and in fact, worked fine for some of the properties like taxonomy values.
Can you suggest , how to prevent overriding of a property which I don’t want to update?
Do you mean you set the 3 properties in ContentNode bean and when you update a document with the ContentNode you see Content-EXIM removes the other existing property, d, in the document?
And, could you link to or upload an image?
Regards,
Woonsan
Yes You’re right @woonsanko
This is the mandatory attribute (property d as per example) which gets removed, when I set ,say, 3 properties in main ContentNode.
This property is present at first level of parent ContentNode and I don’t set it anywhere in code.
There are some sub content-nodes + properties as well, but that’s irrelevant for the use case I guess, so we can ignore them.
I call this method for updating/creating document:
importTask.createOrUpdateDocumentFromVariantContentNode(contentNode,…)
Hi Sarthak,
Basically, Content-EXIM’s WorkflowDocumentVariantImportTask keeps the existing JCR properties in a document variant, only updating data from the input ContentNode object. However, it removes any compound nodes (any subnodes under the document variant node) first and adds new compound nodes based on the input ContentNode object.
This is the sensible default behavior, IMHO. For example, suppose you have three document link mirror (compound) nodes under the document variant node. If your input ContentNode now contains only two link mirror nodes, it makes sense to remove all the existing link mirror nodes and add again the new two link mirror nodes.
But, also, I understand the problem you met now. In your case, you seem to want to keep any existing compound nodes, the hero image link node in your case, even if the input ContentNode doesn’t include that one. So, it’s something to be covered by your customization, not by default in the forge project level, IMHO.
To customize the default behavior, you need to do the following:
ContentNodeBinder by #setContentNodeBinder(ContentNodeBinder) on the WorkflowDocumentVariantImportTask. The default implementation of ContentNodeBinder is org.onehippo.forge.content.pojo.binder.jcr.DefaultJcrContentNodeBinder.DefaultJcrContentNodeBinder and override #removeSubNodes(Node, ContentNode, ContentNodeBindingItemFilter<ContentItem>) to include your custom logic.if block if your hero image link compound in direct child of the document variant, or else block if it is a child compound of another compound node like content-blocks plugin.Regards,
Woonsan
Thanks for the reply Woonsan.
I am using exim version 2.2.0
I inspected DefaultJcrContentNodeBinder and interface ContentNodeBinder
I couldn’t find ‘removeSubNodes’ method to override.
There is no remove* method.
I don’t want both, Hero Image and properties of other child compound elements to be removed.
I can try to figure that out, but firstly , I couldn’t find removeSubNodes to override.
Content-EXIM 2.2.0 should be pulling in jcr-pojo-binding-1.2.0 transitively. [1,2]
You might have been looking at a different version of jcr-pojo-binding module for some reason, depending on how you inspected it.
Woonsan
[1] https://onehippo-forge.github.io/content-export-import/release-notes.html
[2] https://onehippo-forge.github.io/jcr-pojo-binding/release-notes.html
Sorry for miscommunication Woonsan,
exim-core-2.2.0 was present in root POM and I referred to that by mistake.
As we are using hippo 10.2.*, the compatible version for that is exim-core-1.2.14,
which is defined in CMS POM.
Sorry for the confusion.
We tried earlier with exim-core-2.2.0 , but it obviously didn’t work with hippo 10.2.*
Any suggestion you might have?
You can write your own custom ContentNodeBinder, by either extending DefaultJcrContentNodeBinder or copying it, to meet your requirements. Find the relevant source here:
Regards,
Woonsan
Thanks @woonsanko .
I added new implementation for Binder.
I have written the logic for merging now. So, Instead of removing and re-adding,
bind method only updates the properties present in ContentNode.
Its written in generic way, which I hope should work for any use cases.
Would you want me to contribute the same to the exim project as separate binder class?
Hi Sarthak,
That would be great if you can contribute! 
Perhaps your binder implementation could be named to something like MergingJcrContentNodeBinder.
Also, the contribution should made for the JCR POJO Binding project [1] on which Content-EXIM depends, not Content-EXIM.
Thanks,
Woonsan
[1] * https://onehippo-forge.github.io/jcr-pojo-binding/release-notes.html