Making the current implementations easy to change

[Google Code Exporter]

While reading the issue 32 I started to wonder if a similar approach should be 
taken with all the transformation methods in the library. (DoAnchors, DoImages, 
DoLists etc...)

The reason I'm suggesting it is because people already want to modify the 
behaviours of the current transformation methods (see issue 30 and issue 35). 
And right now they can't make these modifications without changing the source 
code directly.

Here's what I have in mind ; There would be an ITransform interface (or maybe 
different interfaces for block level and inline transformation methods)
public interface ITransform {
    public string Transform(string text);
}
And interfaces for the default transformation methods in the library, like :
public interface ITransformAnchors : ITransform {}

A class that implements ITransformAnchors would be responsible for transforming 
the anchor elements :
public class DefaultAnchorTransformer : ITransformAnchors {
    public string Transform(string text) {
        // do reference-style links
        // inline-style links. and so on...
    }
}

So if an end-developer wants to add target="_blank" or rel="nofollow" 
attributes to the anchors (like in the issue 30 and 35) then they would send 
their own class that implements the ITransformAnchors and the Markdown class 
would use that instead.

Or if they want to do more transformations (like adding support for tables etc) 
then they would send an ITransform and Markdown class would run that type's 
Transform() method when it's done with the rest.

Another similar approach would be having a Transformation class :
public class Transformation {
    public string Name { get; set; }
    public Func<string, string> Transform { get; set; }
    public ElementType Type { get; set; } // anchor, image etc
    // and maybe another property for order.
}
And the same idea would apply again.


Any opinions?

Original issue reported on code.google.com by [e-mail] on 9 Oct 2010 at 1:46

[Google Code Exporter]

I don't feel that making every operation an overridable transform is really 
necessary. You Aren't Gonna Need It. (YAGNI).

Even in the case of nofollow, the logic required has nothing to do with 
markdown and logically belongs outside this class. See my response to that for 
more detail.

Original comment by [e-mail] on 12 Nov 2010 at 8:54

[Google Code Exporter]

Original comment by [e-mail] on 12 Nov 2010 at 9:03

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[Google Code Exporter]

Original comment by [e-mail] on 12 Nov 2010 at 9:03

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[Google Code Exporter]

Respectfully, this is an open source project for everyone and anyone, so while 
WAGNI, I might need it and so may others.

Of course the project owners aren't obligated to implement any of this, but 
it's the kind of thing that increases the chance of a project being forked, or 
numerous people duplicating the effort of integrating this kind of thing.

Processing the generated HTML to include this kind of thing afterwards doesn't 
feel right to me.  I want to use a library like this to completely avoid having 
to deal with HTML.  Furthermore it just involves loads more string operations 
on the server which results in unnecessary GC pressure.  A library like this 
should be able to operate on a stream directly to reduce the working set of the 
function.  Providing callbacks as discussed here would allow for that in a 
simple way.  I like the idea.

Original comment by drewnoakes on 18 Nov 2010 at 3:23