This project is read-only.

Textile in ScrewTurn Wiki

Jul 31, 2007 at 3:16 PM
Hi,

I've been using your very nice Textile library to try to implement Textile formatting in ScrewTurn Wiki http://www.screwturn.eu

It works great right out of the gate, but of course it doesn't handle ScrewTurn's wiki links, so I am trying to implement that. Using the standard [[Wiki Link]] format works fine, but I would really like to allow CamelCase wiki words to translate to links (i.e. CamelCase is equivalent to CamelCase

This is proving to be a little trickier. Obviously I need to ignore CamelCase words that are in things like links and img tags, and other things that are already processed by your Textile library. Do you have any suggestions? Do you think this is something best done before or after Textile.NET processing, or, do you think it would be better/easier to implement it in a customized version of Textile.NET. Any help would be greatly appreciated.
Mar 3, 2008 at 1:30 AM
Woops, didn't see this post. I guess you went onto other things since them, but just in case...

In the latest version of Textile.NET you can add new custom formatters to a given instance of a Textile formatter, effectively extending the syntax. You could therefore add one to handle the wiki link format. Another way is to simply handle the wiki links yourself, and pass the transformed text to Textile.NET, which should recognize and preserve the HTML links thus created.

For the CamelCase, though, this is tricky indeed, although the best way is still to do it before the Textile processing, since Textile.NET should again recognize and preserve the HTML links. However, your CamelCase processing will still have to use a kick-ass Regex because it could get as an input some links, or other such things, containing CamelCase words, which are not okay to transform into links. The Regex would have to do some backwards checks, looking for "http://" and other known URI prefixes.
Apr 22, 2008 at 9:39 PM
How do you add custom formatters?


lordabdul wrote:
Woops, didn't see this post. I guess you went onto other things since them, but just in case...

In the latest version of Textile.NET you can add new custom formatters to a given instance of a Textile formatter, effectively extending the syntax. You could therefore add one to handle the wiki link format. Another way is to simply handle the wiki links yourself, and pass the transformed text to Textile.NET, which should recognize and preserve the HTML links thus created.

For the CamelCase, though, this is tricky indeed, although the best way is still to do it before the Textile processing, since Textile.NET should again recognize and preserve the HTML links. However, your CamelCase processing will still have to use a kick-ass Regex because it could get as an input some links, or other such things, containing CamelCase words, which are not okay to transform into links. The Regex would have to do some backwards checks, looking for "http://" and other known URI prefixes.

Apr 29, 2008 at 6:11 PM
The TextileFormatter class has some static methods for registering new formatting states ("stateful" stuff like paragraphs, bulleted lists or tables), and registering block modifiers ("quick" stuff like bold, italics, URLs or images):

  • TextileFormatter.RegisterFormatterState()
  • TextileFormatter.RegisterBlockModifier()

The first method takes the Type of the FormatterState (a type which must be a subclass of FormatterState). The second method takes an instance of a subclass of BlockModifier. Look at the source code, in TextileFormatter's static constructor, to see what default formatter states and block modifiers are registered. You can then look at their source code, or ask more questions here if you can't make it work.

Note that you can also disable some states or block modifiers (SwitchBlockModifier and SwitchFormatterState methods). This is used, for example, if you want to disable some specific formatting (URLs, images, tables, whatever) for security reasons, or for replacing it with your own. It sucks a bit right now, though, because those formatter states and block modifiers are registered statically, so all instances of the TextileFormatter will share the same restrictions and custom additions. I'll have to refactor this in the near future.

If you're wondering why the formatter state registration takes a Type instead of an instance of a FormatterState, that's because, well, the formatting state is stateful. So TextileFormatter will instanciate an object of the appropriate type everytime the conditions for entering that state is met. A classic example is a bunch of nested bulleted lists. You need to retain the state of each list as you pop in and out of them with more nested stuff.
Apr 29, 2008 at 6:12 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.