Skip to content

Conversation

@s-ludwig
Copy link
Member

Makes the entity module API @safe to make it better suited for web app embedding and adds more fine-grained access to Ddoc section contents.

Still contains some "trusted" annotations due to whacky inout semantics, but provides the basis for making the rest of the codebase "safe".
Copy link
Member

@WebFreak001 WebFreak001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rest LGTM

return dst.data;
}

void renderParameters(DdocContext context,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused or undocumented public API

Should this rather return a helper struct that you can foreach on to be more idiomatic? (e.g. opApply)


bool hasSection(string name) const { return m_sections.canFind!(s => s.name == name); }

const(string)[] getRawSectionContent(string name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused or undocumented public API

@s-ludwig
Copy link
Member Author

@WebFreak001: I was focused on making the additional information available consistently with the existing code, but you are right that the current API is not very good. My suggestion for getRawSectionContent would be to instead make Section public and replace getRawSectionContent with a simple sections() getter property and plan for eventually replacing the renderSection* methods with Section.render().

I'm not sure about the opApply/helper struct route for renderParameters, maybe this can eventually also be replaced with a simple parameters() getter property that returns a new parameter struct type, which then also has a render() method. Since there are interactions with the other section related functions to consider, though, I'd really like to postpone a deviation from the existing API structure until there is a clear picture of how a better API would look overall.

Allows to get the unprocessed  Ddoc string for sections in order to support custom special use sections (e.g. "Category:") that are not supposed to be rendered.
Adds the possibility for more fine-grained  rendering of the "Params" section in cases where the name/description table layout is undesirable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants