class CustomRenderer < Markd::Renderer
def strong(node, entering)
end
# more methods following in render.
end
options = Markd::Options.new(time: true)
document = Markd::Parser.parse(markdown, options)
renderer = CustomRenderer.new(options)
html = renderer.render(document)
IMO I don't think this is the best approach, Markd::Renderer is centered around the HTML renderer specifically, so an unsuspecting user may implement a custom renderer that only overrides #strong (for example), expecting the rest of the markdown to be rendered as text—except it's rendered HTML now! It's also not clear what methods can be overridden unless you look into the source code (partially related to #55). I think it would be better if Markd::Renderer was implemented as an abstract class with abstract methods, like an interface:
This way it's clear what methods you can/have to implement. If users just want to override one or more methods like in the README example, they still can do so by extending Markd::HTMLRenderer. WDYT?
Introducing a completely abstract interface seems like a good idea. This would also allow to document the interface independently of a specific implementation.
Per the README:
IMO I don't think this is the best approach,
Markd::Renderer
is centered around the HTML renderer specifically, so an unsuspecting user may implement a custom renderer that only overrides#strong
(for example), expecting the rest of the markdown to be rendered as text—except it's rendered HTML now! It's also not clear what methods can be overridden unless you look into the source code (partially related to #55). I think it would be better ifMarkd::Renderer
was implemented as an abstract class with abstract methods, like an interface:This way it's clear what methods you can/have to implement. If users just want to override one or more methods like in the README example, they still can do so by extending
Markd::HTMLRenderer
. WDYT?