Textpattern CMS

#1 2010-12-04 15:30:26

progo

Member

Registered: 2009-12-11

Posts: 11

[textile] FR: Make it easy to extend Textile

Now I don’t know how this turns when Textile is being separated from TextPattern, but I’ve found it odd that one can’t extend Textile easily. And because the xml tags are long and messy, directly hacking classTextile.php has been my only choice for some things.

Why allow extending Textile? Well you may make good arguments about simple and robust parser but I think such a limitation in a well scaling CMS seems odd. If one could define new tokens to parse textile, it’d easen to create domain specific markup languages for systems. One basic example is math mode similar to LaTeX. My option was to write an additional function to classTextile.php to handle $$ .. $$ pairs.

I also hope that plugins could bind themselves to certain tags. I want syntax highlighting in my code listings, why shouldn’t the plugin rebind the bc block to use the plugin’s functionality instead of the default. All of this I have to write manually in the PHP. Not very sustainable nor stable. One advantage of rebinding default tags is higher level of abstraction. If for example one wanted to change their syntax highlighter from one plugin to another, in traditional¹ way they had to go through all posts and do a search-replace for XML. A bc is a bc, no matter the underlying plugin is.

In the textile engine, this is feasible IME. I’m not a good PHP developer but in general it is doable to enable chainable and rebindable tagging engine. It would take some rewriting but in the end the basic functionality stays the same so no losing backwards compability!

¹ Foxcode example:

<txp:fox_code><notextile>
blahblah
</notextile></txp:fox_code>

Last edited by progo (2010-12-04 15:31:05)

#2 2011-01-10 21:17:29

net-carver

Archived Plugin Author

Registered: 2006-03-08

Posts: 1,648

Re: [textile] FR: Make it easy to extend Textile

Hi Progo,

you may be interested in this post if you haven’t seen it already. It allows some of what you are talking about — by allowing you to redefine or extend the handling of block level constructs (like bc.) but not for glyphs so just doing stuff between the $$...$$ you cite aren’t handled by that feature-test branch.

Feel free to continue the discussion on that thread if you so wish.

---

— Steve