[textile] Textile feature request

jsoo · 2011-01-08 21:10:30

Steve:

First let me say how impressed I am with Textile 2.2. I was so inured to the quirkiness of prior versions that it has taken me a while to realize how much of an improvement Textile 2.2 represents. The new features are excellent, but this pales in comparison to the stability improvements.

I’ve been wondering about the possibilities for adding some kind of user-defined tags to Textile, for use as a domain-level shorthand. Not extending the language per se, but simple substitution of these tags with pre-defined output. A definition file entry might look like this:

txp => <abbr title="Textpattern Content Management System">TXP</abbr>

so that instead of typing

TXP(Textpattern Content Management System)

you type

{$txp}

(just to propose one possible syntax for this)

Gocom · 2011-01-08 21:46:51

Jeff, do you have any suggestions to how to implement this? I’m just interested.

Would the feature be integrated with TXP, and TXP’s localization support and such? Or would Textile itself allow use of optional definition file? And if so, how would possible localization work (like TXP’s textpacks?)?

To me it would make sense if the definition table could be freely extended. Instead of relaying prebuild definition file or whatnot, the table could be build from TXP’s plugin or even from TXP’s core.

I personally don’t really have any need for this type of feature, but it sound nice. I would rather take better callbacks in TXP’s article saving that would allow same, but I’m positive that TXP5 will take care of that :-)

maniqui · 2011-01-08 21:59:55

Hi jsoo,
I’ve thought about a similar feature, and I’ve even exchanged a few mails with Steve (net-carver) and Stef (Bloke) about it.
Stef showed some interest. Let me look through the pile of emails… oh, here it is.
I will wrap it in Textile bc.. code to make it easier to post it (sorry)

*Idea 3: Textile meet yields meets {smd}: custom Textile codes. 
Basically, you create (where?) some kind of HTML placeholder/wrapper, give it a name, and then, you can use that name as a Textile code.*

In pseudo-code:

    @def note = <p class="note"><strong>{content}</strong></p>

(here, we defined a new Textile code, named "note").
Then, we use it somewhere in our article:

    p. And that's the end of the story.

    note. No animals have been eaten alive during the make of this movie.

Which will render:

   <p> And that's the end of the story.</p>

   <p class="note"><strong>No animals have been eaten alive during the make of this movie.</p>

Now, one example a bit more complex:

   @def note = <p class="{class}"><strong>{content}</strong></p>

   note(important). There is going to be a cra$h.

Which will render:

   <p class="important"><strong>There is going to be a cra$h.</p>

That was my original idea. And I’ve been giving a few more spinnings in my head during the last days, and I think it could be a perfect match with TXP, for “dumbing-down” some <txp:tag /> for making it easier to clients to add stuff to their articles.
Let me try to explain with a few quick, dirty, basic examples.

 Definition of the custom Textile tag:

   @def my_img = <txp:smd_gallery id="{%1}" form="float_{%2}" />

Usage of this custom Textile tag:

    my_img. 4, left

After saving article, this is what it gets saved on Body_html column of textpattern table

    <txp:smd_gallery id="4" form="float_left" />

As you can see, there are some positional arguments, somehow command-line style.

Also, there is nothing magic here. It’s not “Textile playing nice with TXP”. It’s just Textile doing its job, and saving the rendered plain text, which, in this example, happens to be some TXP code. It could be another templating system, another language, who knows.

You could go really far with this, as the definition of the custom tag could include more complex code, including stuff like conditionals (ie, smd_if) for testing this positional “arguments”.

I think this could really open up the game for Textile, and also for TXP. by making it easier for end users to add/embed “complex” chunks of code into their post, without the risk of breaking the page layout.
And that goes really close with one of the motivations behind Textile, imho: if you write your Textile badly/wrongly, it won’t get parsed, and you won’t end up with broken HTML/layout.

This makes me tangentially remember the oembed spec, which I’ve tried a few days ago and I think it’s a great way to easily embed content from providers (like YouTube, Twitter, Vimeo, SoundCloud, etc) by just posting a simple link to the resource.

maniqui · 2011-01-08 22:24:24

Let me add a few more examples.

HTML-only:

Definition:

@def my_figure = <figure><img src="/images/{%1}" /><figcaption>{%2}</figcaption></figure>

Usage:

my_figure. 4.jpg, Kitten nom-nom-noming

Renders:

<figure><img src="/images/4.jpg" /><figcaption>Kitten nom-nom-noming</figcaption></figure>

HTML + TXP code:

Definition:

@def my_figure = <figure><txp:image id="{%1}" /><figcaption>{%2}</figcaption></figure>

Usage (in this case, no need to pass the image file extension, just the id):

my_figure. 8, Me doing the duck face

Renders:

<figure><img src="/images/8.jpg" /><figcaption>Me doing the duck face</figcaption></figure>

HTML + TXP code, more complex:

Definition (in this case, the code is multiline to make it easier to read in this example):

@def my_figure = 

<txp:smd_if field="{%3}" operator="eq" value="link">
### Link thumbnail to larger image
   <figure><txp:thumbnail id="{%1}" link="1" /><figcaption>{%2}</figcaption></figure>
<txp:else />
   <figure><txp:image id="{%1}" /><figcaption>{%2}</figcaption></figure>
</txp:smd_if>

Usage:

my_figure. 10, Me doing the duck face again, link

Renders:

<figure><a href="/images/8.jpg"><img src="/images/8t.jpg" /></a><figcaption>Me doing the duck face</figcaption></figure>

——

Of course, if this idea has any merits, it should be polished further. For example, in the above example, I’ve used commas as separators, but then, if end user wants to use a comma in the figcaption text (again, following the above example), then it has to be somehow escaped. Maybe a pipe would make a better default separator…

jsoo · 2011-01-08 22:30:13

Gocom wrote:

Jeff, do you have any suggestions to how to implement this? I’m just interested.

I was thinking of this as a Textile feature. Txp could then of course easily take advantage of it, allowing user-defined “tags” at any level: global, per-section, per-article, etc. (Localization: I guess you could — only use the extended syntax if there is a definition matching the language preference of the Txp user editing the article.) I was thinking of a Txp plugin to configure Textile to add the user definitions, which could be external files, prefs, separate DB table.

Julián:

I’m a little more leery of suggesting something as open-ended as you suggest. Though allowing new block elements is probably a lot easier than allowing new phrase elements. It’s a fascinating idea, I just don’t know how difficult it would be to implement. (I don’t know how difficult my idea would be, either, but I suspect it would be fairly easy.)

net-carver · 2011-01-09 00:09:41

Jeff, Julián

Thanks for the feedback. I’ll chew this over a little more before I extend my comments on these ideas.

Now, hijacking the thread a little if I may be allowed for a moment…

Julián

Any feedback for me on the multiple note-list feature you requested — I’ve been waiting for some since last September-ish?

All

Anyone else want to try out multiple notelists and give me some feedback — just download from the notes branch. NB: this is a feature-test branch only. Please use the master branch for all live deployments as it contains security patches that I don’t bother applying to other branches.

Edited to add: Here’s an example of using named notelists…

French cheese production is classified under four categories, and PDO/AOC rules dictate which category(ies) each protected cheese may be assigned to; Fermier[#Cheese:Fermier], Artisanal[#Cheese:Artisanal], Coopérative[#Cheese:Coopérative] or Industriel[#Cheese:Industriel]. Of the four categories, it is the opinion of this author, that Artisanal[#Cheese:Artisanal] cheeses are the best available.

note#Cheese:Unrefereced. See "Appellation d'Origine Contrôlée":http://en.wikipedia.org/wiki/Appellation_d%27Origine_Contr%C3%B4l%C3%A9e (AOC) system for more details.

note#Cheese:Fermier. A farmhouse cheese, which is produced on the farm where the milk is produced.

note#Cheese:Artisanal. A producer producing cheese in relatively small quantities using milk from their own farm, but may also purchase milk from local farms.

note#Cheese:Coopérative. A dairy with local milk producers in an area that have joined to produce cheese. In larger coopératives quantities of cheese produced may be relatively large, akin to some industriel producers (many may be classed as factory-made[#Industriel]).

note#Cheese:Industriel. A factory-made cheese from milk sourced locally or regionally, perhaps all over France (depending on the AOC/PDO regulations for specific cheeses).

notelist:α+. Cheese

End of edit. If feedback on multiple named notelists is good I’ll merge it into master.

Ok — Sorry for the slight thread hijack Jeff.

Last edited by net-carver (2011-01-09 06:40:28)

net-carver · 2011-01-09 21:31:51

Jeff

Back on track with a question: Am I right in thinking that what you are suggesting would be similar to a macro pre-processor that sits inside Textile? From the look of your example, you’d be expecting the substitutions to be done prior to any of Textile’s existing processing right?

jsoo · 2011-01-10 00:48:46

Not necessarily. If this is a feasible idea, and if it’s as easy to do before regular Textile processing begins, then I think that would be best. But I think it would be useful either way.

net-carver · 2011-01-10 01:27:09

Jeff

If all your substitutions are known prior to initiating a parse of the textile document I’d expect it easier to just do something like…

$subs = array( '{$txp}' => '<abbr title="Textpattern Content Management System">TXP</abbr>',
# others as needed...
);
$ready_to_be_textiled = strtr( $source_text, $subs );

…and just textile that. If the definitions of these substitutions were to fall at the start (or even throughout) a document, as the author thought of them, then something more complex would be needed.

All

Due to the above, and multiple other requests for new block-level elements, please check out & try this commit. This is my first shot at opening up textile to plugins. Only block-level handlers are supported but it’s a first step. If you want to download and try it, make sure you download from branch feature-block-plugins. YMMV and don’t subject your live sites to this.

jsoo · 2011-01-10 01:40:25

net-carver wrote:

If all your substitutions are known prior to initiating a parse of the textile document I’d expect it easier to just do something like…

Ah, of course. Thanks for that.

net-carver · 2011-01-11 12:31:27

Jeff

I’ve opened a new issue for this idea as I (think I) can think of a way to generalise your request and also allow for parse-time variable substitutions too. It will need some more thought but should be possible.

Julián

Your ideas are interesting and could probably be taken care of by the now in-test block-level textile-plugins feature. I can imagine a plugin that allows you to define custom blocks (with substitutions) and then apply them.

All

Feel free to extend this discussion, or start new ones, on the issue tracker as there are other folks (from other CMSs) starting to use it and your comments will be visible to them there.

Textpattern CMS

Textpattern CMS support forum

#1 2011-01-08 21:10:30

[textile] Textile feature request

#2 2011-01-08 21:46:51

Re: [textile] Textile feature request

#3 2011-01-08 21:59:55

Re: [textile] Textile feature request

#4 2011-01-08 22:24:24

Re: [textile] Textile feature request

#5 2011-01-08 22:30:13

Re: [textile] Textile feature request

#6 2011-01-09 00:09:41

Re: [textile] Textile feature request

#7 2011-01-09 21:31:51

Re: [textile] Textile feature request

#8 2011-01-10 00:48:46

Re: [textile] Textile feature request

#9 2011-01-10 01:27:09

Re: [textile] Textile feature request

#10 2011-01-10 01:40:25

Re: [textile] Textile feature request

#11 2011-01-11 12:31:27

Re: [textile] Textile feature request

Board footer