LightGuard / asciidoc-splitter

A splitter utility for helping create modular docs from chapter files.
BSD 2-Clause "Simplified" License
8 stars 8 forks source link

Better handle cases where entire modules are conditionalized in chap/assembly files #80

Closed sterobin closed 3 years ago

sterobin commented 3 years ago

Current behavior

Some modules/sections are conditioned, such as to apply for community but not enterprise, or vice versa.

For example, the following two modules in this DMN chap file apply to Kogito community docs but not to Kogito enterprise docs, and thus the two module sections in the chapter file are conditionalized accordingly with an ifdef before the first and an endif after the second:

ifdef::KOGITO-COMM[]

[id="ref-dmn-feel-enhancements_{context}"]
=== FEEL enhancements in {PRODUCT}

{PRODUCT} includes ...
...

[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...
...

endif::[]

The expectation is that the above condition tags will be left in place in the converted assembly file surrounding the two converted module includes, as follows:

ifdef::KOGITO-COMM[]

include::ref-dmn-feel-enhancements.adoc[]

include::modules/dmn/ref-dmn-model-enhancements.adoc[]

endif::[]

Instead, what happens today is the following:

Target behavior

Retain all ifdef/endif conditions as they are, including condition tags that should surround a module include in the assembly file not just content in the module file.

This might be tricky because, how can the splitter know if an endif at the end of a module is the close of a condition that encapsulates the entire module and should thus be conditioned in the assembly file VS. just the close of conditioned content within that module and thus be conditioned within the module file? The answer to that determines whether to retain the conditions in the assembly (surrounding the includes) or within the module file.

Example, this is a condition to enclose the includes in the assembly:

ifdef::KOGITO-COMM[]

[id="ref-dmn-feel-enhancements_{context}"]
=== FEEL enhancements in {PRODUCT}

{PRODUCT} includes ...
...

[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...
...

endif::[]

Whereas this is a condition to enclose just a portion within the module file:

[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...

ifdef::KOGITO-COMM[]
And also does some community stuff.
...

endif::[]

Note how in both cases the second file ends with an endif exactly the same way. Asciidoc doesn't have any trouble because it tracks back to the start ifdef tag wherever it is and removes it out regardless.

So is there a way for the splitter to detect whether to condition out entire modules and retain the ifdefs in the assembly vs. condition out module content and retain the ifdefs only in the module file? It seems to struggle with that today.

Resources

LightGuard commented 3 years ago

Please provide test case. I thought I had conditionals figured out.

sterobin commented 3 years ago

As discussed in chat, you should have all the info and links that you need above to create a branch or download the zip for a test case.

LightGuard commented 3 years ago

I hate conditionals. Have to think on this a lot more. The way things are done both within asciidoctor and what I've done in the splitter don't make this easy.