Trouble extending my custom plugin

[Michael Morrison]

Hi All -

I've been tilting at a few windmills lately trying to understand how to extend my custom DITA OT plugin.  I'm sure I'm overlooking something obvious, but nothing I've tried so far works.

Here's what I have: 

• myPDFplugin, with <require plugin="org.dita.pdf2"/> in its plugin.xml file.

Here’s what I want: 

• myPDFplugin, with <require plugin="org.dita.pdf2"/> in its plugin.xml file.
• myOtherPDFplugin, with <require plugin="com.mcm.myPDFplugin " importance="required"/> in its plugin.xml file.  I also have <transtype name=" myOtherPDFplugin " extends=" myPDFplugin "/> in the plugin.xml file.

 

What I want is to customize a few of the \cfg\fo\attrs files and a few of the \cfg\fo\xsl files in myOtherPDFplugin, with the bulk of the processing managed by the files in the cfg\ folder of myPDFplugin.

However, when I generate a PDF using the myOtherPDFplugin plugin, I don’t see any of the processing or formatting from myPDFplugin, instead I only see processing and formatting from the base DITA OT “pdf2” plugin.  

In my build.xml file for myOtherPDFplugin, I have the following property in my <target name="dita2myOtherPDFplugin.init"> target: 

• <property name="customization.dir" location="${dita.plugin.com.mcm.myOtherPDFplugin.dir}/cfg"/>

Whereas the customization.dir property for my myPDFplugin Is “${dita.plugin.com.mcm.myPDFplugin.dir}/cfg", and I suspect that this location is never evaluated during the PDF generation because the value "customization.dir" appears in both of my plugins’ dita2xxx.init targets, and only the highest priority one applies.

What am I missing? 

I should be able to “subclass” my own custom plugin, and not have to copy all of the cfg files from one to the other, but only modify (and include in custom.xml) a subset in the “subclass” plugin from the base plugin.  There’s some subtlety I’ve overlooked, clearly.  If you’ve successfully implemented a “subclass” plugin (where your pluginB extends your pluginA, which in turn uses the DITA OT pdf2 plugin), let me know how you made it work.

Thanks,

Michael

[Radu Coravu]

Hi Michael,

Only one "customization.dir" can be set via a DITA OT PDF customization plugin. So the base PDF plugin does not merge customization dir folders from multiple PDF customization plugins, it uses only one of them, probably the first one that it loads.

There is a plugin extension point named "dita.xsl.xslfo" which allows contributing multiple XSLT stylesheets from multiple PDF plugins, stylesheets which are all imported and used for PDF generation. It's used in the plugin.xml something like:

<plugin id="idvalue">

....

<feature extension="dita.xsl.xslfo" value="customFO.xsl" type="file"/>

...

    </plugin>

https://www.dita-ot.org/dev/extension-points/extension-points-in-org.dita.pdf2.html#org.dita.pdf2-ext__dita.xsl.xslfo

Regards,

Radu

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/dita-ot-users/5c34acad-78f1-44b8-b630-f2fbdf46cd02n%40googlegroups.com.

[Michael Morrison]

Radu - 

Thanks for your advice.  

My "myPDFplugin" includes 27 files in the cfg/fo/attr folder and 24 files in the cfg/fo/xsl folder.  My plan for my "myOtherPDFplugin" is to update the templates in files with the same names as those in the "myPDFplugin" plugin (which in turn uses the same file names as those in the DITA OT pdf2 plugin).

Your suggestion to use the "dita.xsl.xslfo" extension would require that all of my template updates for "myOtherPDFplugin" be included in a single file. Given the requirements for that plugin, this approach does not work.

However, further investigation provided me with a solution that, while not entirely elegant, does work.

Within the cfg/fo/attr/custom.xsl and cfg/fo/xsl/custom.xsl files for the "myOtherPDFplugin" plugin, I have now included all of the XSL files from the "myPDFplugin" plugin (with my base functionality templates), and also include the XSL files (with modified templates) for the "myOtherPDFplugin" plugin. For example:

<!-- MCM: Imported "attr" files from the "myPDFplugin" plugin; base formatting is specified here -->    

        <xsl:import href="../../../../com.mcm.pdf/cfg/fo/attrs/commons-attr.xsl"/>

<-- ... the other 21 import statements omitted for brevity ... -->

<!-- MCM: Imported "attr" files for the "myOtherPDFplugin" plugin -->

        <!-- MCM: Only files with changed templates for the "myOtherPDFplugin" are listed; all base formatting comes from the "myPDFplugin" plugin -->

        <xsl:import href="commons-attr.xsl"/>

<-- ... the other modified files omitted for brevity ... -->

This approach should work for two reasons:

- The plugin.xml file for the "myOtherPDFplugin" plugin includes the following statement:

<require plugin="com.mcm.pdf" importance="required"/> <-- the "myPDFplugin" plugin -->

Thus, all of the import statements from "myPDFplugin" should always be available; if they are not, the <require> statement should fail the build

- The last-specified import statement has highest priority within the XSL processing, so it will process the modified templates for "myOtherPDFplugin" before processing similar templates from "myPDFplugin".

With this approach, the "customization.dir" for "myOtherPDFplugin" points to the ${dita.plugin.com.mcm.myOtherPDFplugin.dir}/cfg" folder, and the similar folder for "myPDFplugin" is not referenced or needed.

Based on my initial testing, this solution works.  Let me know if I've overlooked anything important.

Thanks, 

Michael

[Radu Coravu]

Hi Michael,

To add a dash of elegance in xsl:imports you can also use plugin IDs like:

<xsl:import href="plugin:org.dita.html5:xsl/dita2html5Impl.xsl"/>

will import for the "org.dita.html5" plugin's folder the "dita2html5Impl.xsl". So "org.dita.html5" is the ID of the plugin, not the plugin folder name.

Regards,

Radu

To view this discussion on the web, visit https://groups.google.com/d/msgid/dita-ot-users/54eb666e-cbbd-4632-b217-deac343af9ean%40googlegroups.com.

[Michael Morrison]

Radu  -

Thanks again.  I've changed my import statements to match your suggested syntax:

        <!-- MCM: Imported "attr" files from the "myPDFplugin" plugin; base formatting is specified here -->    

        <xsl:import href="plugin:com.mcm.pdf:cfg/fo/attrs/commons-attr.xsl"/>

        <-- ... the other 21 import statements omitted for brevity ... -->

        <!-- MCM: Imported "attr" files for the "myOtherPDFplugin" plugin -->

        <!-- MCM: Only files with changed templates for the "myOtherPDFplugin" are listed; all base formatting comes from the "myPDFplugin" plugin -->

        <xsl:import href="commons-attr.xsl"/>

        <-- ... the other modified files omitted for brevity ... -->

And it works.