Allow overridable anchor text

[danives3d]

Based on the existing use of predef_urls to set URLs for predefined blocks such as ref in the docs examples, in my project we came across a need to be able to dynamically set the URLs as well as titles when rendering a page.

This just adds the facility of being able to pass through a map in the same manner as predef_urls and predef_titles that will override the text that was set, meaning you can do things like

$content = "[page_14]";
$predef_urls = array('page_14' => '<dynamically generated page url>');
$predef_texts = array('page_14' => '<dynamically generated page title>');

[michelf]

Interesting. This brings an unexpected behavior: what is in the brackets is usually the link's text and is never replaced by something else. What should happen if the Markdown document has something different for the text in the link? like this:

See the definition on [the previous page][page_14].

While I like the idea, I'm not quite sure the syntax used for links is the right syntax to use here.

[danives3d]

I came to realise that when using it; however I think its a difficult one to judge. In some instances, people might want the text to always be overridden - regardless of whatever is placed in front of it - to maintain some form of standardisation.

The other alternate is that the logic could be changed so that unless there is already text in front of the link, use the provided predefined text. This would then allow people to override it accordingly, while providing 'default' text.

I think the solution in this case is potentially a marry of both worlds - the addition of another variable to the Markdown class, that when true always override link text - otherwise fallback to providing the link text as a default. I don't know what that variable would be called, something like override_text or similar.

Do you think that solution would be a good middle ground? If so I'll implement and update the PR accordingly :)

[michelf]

That makes some sense, but if you're going to replace the text for something else I think it'd be best if it was more explicit.

A solution would be to implement a "wiki" link syntax, which would basically forward things to a callback function set by the application using the parser to do about anything. No callback provided would make the parser ignore that syntax.

[[page_14]]

The callback would be taking "page_14" and return some HTML. Or it could return null to bail out which would leave that as pure text.

The downside of this is that it's more implementation work in the parser than piggy-backing on the current link syntax.