You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be possible to emit NodeSeq objects instead of only Strings when processing Markdown.
The best way to achieve this is to refactor the Decorator and make it more generic. This needs some slight changes to callbacks for some elements. With a more general Decorator any kind of output can be produced.
The problematic part: with inline xml/html and xml blocks it is possible to create markdown that would result in invalid XML (sticking to plain markdown syntax will always produce wellformed XML in Actuarius.)
How should this be handled?
Variant A: Invalid inline XML/HTML / XML blocks cause(s) processing to throw an Exception
Variant B: Invalid inline XML/HTML / XML blocks is wrapped in an "Unparsed" NodeSeq (This is a quite ugly solution, as a consumer of NodeSeq would generally assume that he gets valid XML)
Variant C: Add a callback for these cases to the Decorator and let the decorator decide.
I favor Variant C with a default implemenation for a NodeSeq Decorator that throws exceptions when encountering invalid XML and a default implementation for a String Decorator that just outputs what it gets (current behavior)
The text was updated successfully, but these errors were encountered:
What I currently do in Hoisted is to use Lift's Html5 parser to parse the code blocks. The Html5 parser is very, very forgiving and generally results in reasonable HTML. That combined with option C would lead to a good result.
It should be possible to emit NodeSeq objects instead of only Strings when processing Markdown.
The best way to achieve this is to refactor the Decorator and make it more generic. This needs some slight changes to callbacks for some elements. With a more general Decorator any kind of output can be produced.
The problematic part: with inline xml/html and xml blocks it is possible to create markdown that would result in invalid XML (sticking to plain markdown syntax will always produce wellformed XML in Actuarius.)
How should this be handled?
Variant A: Invalid inline XML/HTML / XML blocks cause(s) processing to throw an Exception
Variant B: Invalid inline XML/HTML / XML blocks is wrapped in an "Unparsed" NodeSeq (This is a quite ugly solution, as a consumer of NodeSeq would generally assume that he gets valid XML)
Variant C: Add a callback for these cases to the Decorator and let the decorator decide.
I favor Variant C with a default implemenation for a NodeSeq Decorator that throws exceptions when encountering invalid XML and a default implementation for a String Decorator that just outputs what it gets (current behavior)
The text was updated successfully, but these errors were encountered: