Page 1 of 1

Specific DocumentTypeAdvancedCustomRuleMatcher

Posted: Wed Apr 05, 2023 11:58 am
by Johann
Hello,

I am using Oxygen 25.0.0.0 version.


I need to have specific framework files associated to XML files that respond to a certain xpath (not in root node).
These framework files inherit from a base framework.
So, I tried this with exf files.

I have my base framework in exf with this association rule:

Code: Select all

 
  <associationRules>
    <addRule rootElementLocalName="test" fileName="*.xml"
      javaRuleClass="" attributeLocalName="noNamespaceSchemaLocation"
      attributeNamespace="http://www.w3.org/2001/test" attributeValue="*test.xsd"
    />
  </associationRules>
  
The specific descendant *exf file is like that:

Code: Select all


<?xml version="1.0" encoding="UTF-8"?>
<script xmlns="http://www.oxygenxml.com/ns/framework/extend"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xsi:schemaLocation="http://www.oxygenxml.com/ns/framework/extend http://www.oxygenxml.com/ns/framework/extend/frameworkExtensionScript.xsd" base="base - framework">
  <name>specific - framework</name>
  <description/>
  <priority>High</priority>

  <associationRules>
    <addRule rootElementLocalName="test" fileName="*.xml"
      attributeLocalName="noNamespaceSchemaLocation"
      attributeNamespace="http://www.w3.org/2001/test" attributeValue="*test.xsd"
    />
    <addRule javaRuleClass="custom.ruleMatcher.CustomDocumentTypeCustomRuleMatcher" />
  </associationRules>



  <author>
    <css>
      <addCss path="${frameworks}/specific.css" position="after" />
    </css>

  </author>

</script>

First question:
I have the impression that the specific framework does not naturally inherit the association rules from the base framework and that it is necessary to rewrite all the rules.
It's not the same mechanism as for CSS. Can you confirm the behaviour?

This is the class CustomDocumentTypeCustomRuleMatcher that I tried:

Code: Select all

public class CustomDocumentTypeCustomRuleMatcher extends DocumentTypeAdvancedCustomRuleMatcher {

    @Override
    public boolean matches(String systemID, String rootNamespace, String rootLocalName,  String doctypePublicID,
        Attributes rootAttributes, Reader contentReader){

        LOGGER.debug("matching?");
        boolean isMatching = false;

        try {

            char[] charBuffer = new char[8 * 1024];
            StringBuilder stringBuilder = new StringBuilder();
            int numCharsRead;
            while ((numCharsRead = contentReader.read(charBuffer, 0, charBuffer.length)) != -1) {
                stringBuilder.append(charBuffer, 0, numCharsRead);
            }          
            LOGGER.debug("String: {}", stringBuilder.toString());
        } catch (Exception e) {
            LOGGER.error("Exception during matching rule");

        }

        return isMatching;
    }

    @Override
    public String getDescription() {
        return null;
    }
}
Second question:
When I open a document, I find that I go through this method many times (between 5 and 10 times when I open the document for the first time) and that the content of the document I am logging (which I should be using my Xpath test on) is not always complete.
Sometimes I only have:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
And sometimes I get all the expected content.

[UPDATE] The content seems no te be totally available when the document opened is in read-only mode. Despite this, whether we are in read-only or in edit mode, we need to access the content of the document to test the xpath.

I'm a bit surprised by these behaviors.
Why so many passes in this "matches" method? Why is the content of contentReader not always complete? Given that I will have to call an xpath in this method to validate or not the association and given the number of calls that are made at the moment, is this a good approach in terms of performance?
Is there a problem with my approach or implementation?

Thank you in advance for your help,

Johann

Re: Specific DocumentTypeAdvancedCustomRuleMatcher

Posted: Mon Apr 10, 2023 12:29 pm
by alex_jitianu
Hello,
First question:
I have the impression that the specific framework does not naturally inherit the association rules from the base framework and that it is necessary to rewrite all the rules.
It's not the same mechanism as for CSS. Can you confirm the behaviour?
They should be inherited. If you go to Options->Preferences... on page Document Type Associations and double click the entry created for your EXF file you'll be able to inspect the framework that was created out of the script. Do you see the association rules from the base ?
Second question:
When I open a document, I find that I go through this method many times (between 5 and 10 times when I open the document for the first time) and that the content of the document I am logging (which I should be using my Xpath test on) is not always complete.
I'' test this behavior and get back to you. Instead of performing XPath, perhaps you can rely on a SAX parsing to identify the condition?

Best regards,
Alex

Re: Specific DocumentTypeAdvancedCustomRuleMatcher

Posted: Tue Apr 11, 2023 5:40 pm
by Johann
Hello,

Indeed the EXF "child" inherits the association rules from its base.
I confirmed it with Oxygen Editor.

This confirms also my questions for point 2. I should have passed in the "matches" method of CustomDocumentTypeCustomRuleMatcher only when a document meets the association rules of my base framework.
However, no matter which document I open, I enter the "matches" method of CustomDocumentTypeCustomRuleMatcher.

Regards,

Johann

Re: Specific DocumentTypeAdvancedCustomRuleMatcher

Posted: Wed Apr 12, 2023 5:14 pm
by alex_jitianu
Hi Johann,
I should have passed in the "matches" method of CustomDocumentTypeCustomRuleMatcher only when a document meets the association rules of my base framework.
However, no matter which document I open, I enter the "matches" method of CustomDocumentTypeCustomRuleMatcher.
If I understand it correctly, you expect the rules from the base framework to filter a lot of cases so that your performance-taxing "matches" method gets called less times. Unfortunately, it doesn't behave like this. It's an OR not an AND. So for a document that doesn't match, all rules will be tested.

Best regards,
Alex