Update Developer Guides #3088
Update Developer Guides #3088
Conversation
docs-developer/src/doc/docs/developer_guide/architecture/architecture_overview.md
Outdated
Show resolved
Hide resolved
| * `Input` - generalization of sources, by default Kotlin / Java sources, but could be virtually anything | ||
| * `Documentables` - unified data model that represents _any_ parsed sources as a tree, independent of the source | ||
| language. Examples of a `Documentable`: class, function, package, property, etc | ||
| * `Pages` - universal model that represents output pages (e.g a function/property page) and the content it's composed of |
There was a problem hiding this comment.
I would clarify that the universal model is independent of the target format output.
There was a problem hiding this comment.
I think it's worth trying to keep the architecture overview page short and concise, and give clarifications on the dedicated pages.
Here, the word "universal" and the sentence "Not to be confused with .html pages" are implying that it's independent, and it's explained in more detail on the page/content model page.
I've added hyperlinks to the names so that it's easier to find details
| * `Pages` - universal model that represents output pages (e.g a function/property page) and the content it's composed of | ||
| (lists, text, code blocks) that the users needs to see. Not to be confused with `.html` pages. Goes hand in hand | ||
| with so-called "Content model". | ||
| * `Output` - specific output format like HTML / Markdown / Javadoc and so on. This is a mapping of the pages/content |
There was a problem hiding this comment.
I am not sure that Javadoc is worth mentioning since it has no Content Model at all.
There was a problem hiding this comment.
But this bullet point is about the output abstraction in the context of the architecture overview, not about the implementation details of the Javadoc output format? I don't think it should matter as long as the reader understands the general concept of how it might work
docs-developer/src/doc/docs/developer_guide/architecture/data_model/documentable_model.md
Outdated
Show resolved
Hide resolved
docs-developer/src/doc/docs/developer_guide/architecture/data_model/documentable_model.md
Outdated
Show resolved
Hide resolved
docs-developer/src/doc/docs/developer_guide/architecture/data_model/extra.md
Outdated
Show resolved
Hide resolved
docs-developer/src/doc/docs/developer_guide/architecture/data_model/page_content.md
Outdated
Show resolved
Hide resolved
docs-developer/src/doc/docs/developer_guide/architecture/data_model/page_content.md
Show resolved
Hide resolved
docs-developer/src/doc/docs/developer_guide/plugin-development/introduction.md
Outdated
Show resolved
Hide resolved
(cherry picked from commit f7bd2ce)
Checked the Developer guides about any incorrect information in regards to the analysis refactoring - everything looks good.
Made some changes as I read through, mostly based on what I learned from working with our technical writers and writing Dokka's user-facing documentation.
Also renamed the module, otherwise having
mkdocsall by itself is not very descriptive, especially when there is already adocsmodule next to it (which should ideally bedocs-useror something)