docToolchain / docToolchain

a AsciiDoc Toolchain for technical Software Documentation, focused on Software Architecture Documentation
https://doctoolchain.github.io/docToolchain/
MIT License
750 stars 237 forks source link

Allow to publish pages in sub-directories without order defined #878

Open jmini opened 2 years ago

jmini commented 2 years ago

Is your feature request related to a problem? Please describe.

After the change introduced with https://github.com/docToolchain/docToolchain/issues/692, it feels more natural to have a tree structure like this:

src/docs
├── ...
├── 30_tri
│   ├── index.adoc
│   ├── foo
│   │   ├── index.adoc
│   │   ├── lorem.adoc
│   │   └── ispum.adoc
│   └── bar
│       ├── index.adoc
│       ├── a.adoc
│       ├── b.adoc
│       └── c.adoc
├── ...

The pages inside 30_tri/foo and 30_tri/bar have no order defined in their file name (example: 30_tri/foo/lorem.adoc and not 30_tri/foo/10_lorem.adoc) and have no jbake-order attribute.

In that case they are generated as draft.

If you look at the corresponding tmp file build/microsite/tmp/site/doc/30_tri/foo/lorem.adoc you see following definitions:

:jbake-status: draft
:jbake-order: -1
:jbake-type: page_toc
:jbake-title: Lorem
:jbake-menu: tri

This is because of this code:

https://github.com/docToolchain/docToolchain/blob/64945cc9f0091d14019767f83b970a9256be85e6/scripts/generateSite.gradle#L265-L269

Describe the solution you'd like

There should be a way to tell that you

If we can't break the current behavior, then I would suggest that if the jbake-status attribute is explicitly set to published the logic inside generateSite.gradle should not set it back to draft.

Describe alternatives you've considered

The current work-around is to set an explicit :jbake-order: attribute in the file, or to rename the file name to have the order as prefix (10_lorem.adoc) but this feels wired.

rdmueller commented 2 years ago

the intention of this code is to hide adoc files like config.adoc which are just included but shouldn't be rendered on their own.

But I do understand this problem and think your proposed change might be a good default.

We could check for a config value - if it exists, use the new behaviour, if not, it is an older project and we stay with the old behaviour.

what do you think?