(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.


Multiline Placeholder Proposal#

I've added a link to MultilinePlaceholderProposal, which Gregor Hagedorn must have missed. The advantage of MultilinePlaceholderProposal is that it begins with a globally unique identifier (reversed domain name, like packages in Java).

--YvesPiguet, 27-Feb-26

Yes, I am new here, thanks! I am not sure why the multiline placeholder has to start on a new line prevents it from being usable in a large number of extension cases. I clarified that the Generic Extension Element may start anywhere, and may contain line breaks.

-- Gregor Hagedorn, 2007-02-27

Generic Extension Element Proposal#

I've been wanting to discuss this particular aspect of the proposal, just waited for the page to settle down. I believe that while we can suggest a plugin-naming scheme, the exact solution used is up to the wiki engine developer. It's very similar situation to how the page names in links and image names are treated -- the existing engines have such a wide range of working solutions that it would be impossible to come up with one that everyone agrees on.

Besides, the domain-like notiation is unnecessarily elaborate for something that is in common everyday use. It's ok for things like DTD that are usually copy-pasted or included in ready-made templates. It's ok for programming languages -- especially when you make some aliases to them anyways. But it'd be unacceptable to write about that <<unaffiliated.radomir.dopieralski.macro.latex source="$x_2$">> symbol as referenced in <<unaffiliated.radomir.dopieralski.macro.latex source="$x_2+y=c$">> formula using these elaborate names.

I say that leaving the plugin-naming conventions to the wiki engine has even more sense that for page names and images -- because these extensions cannot be moved between wikis anyways, so we really don't need any interoperability inside the box.

-- RadomirDopieralski, 2007-02-26

I think I would like to see this expanded alittle to optionally allow alternative content. Which would serve two purposes.

  • When wiki engine doesn't know a plugin it can use the alternative. Like HTML's object element.
  • Plain text markup can still make sense.

As for naming, I do think the dotted form is excessive. And certainly wouldn't want the plugging name embeddeded directly in the wiki markup. If I wrote a different latex plugin with the same interface as unaffiliated.radomir.dopieralski.macro.latex, I won't want to have to change the markup.

-- JaredWilliams, 2007-02-26

You have the choice between possible name clashes which must be handled in an ad hoc fashion, or some unique identifier. With unique identifiers, you can have a central repository, which is painful to manage, or a way to delegate naming to multiple people like with my proposition, with slightly longer names (of course nobody would ever choose something like unaffiliated.radomir.dopieralski.macro.latex). If you accept name clashes, it isn't worth having it in the standard, and it isn't worth having alternative contents because you can't be sure you won't map to your plugin something else with the same name.

To please everybody, I'd suggest that names with dots be reserved for reversed domains for people who care about the issue, but by experience, I feel it's a loosing battle.

-- YvesPiguet, 2007-02-27

The canonical domain name for my university's faculty is wmid.amu.edu.pl. This is actually very short, as we use acronyms both for the unversity and the faculty name. Other universities/faculties domain names tend to be longer. A lot of development happens on universities: you'd then have pl.edu.amu.wmid.macro.latex (the "macro" keyword is needed to distinguish it from similar plugins, like parser.latex, colorizer.latex or import.latex).

I agree about the choice between possible clashes and nice and clean namespace, and also about the benefits that allow you to make central repositories, indexing, put important documentation online, etc. But I believe that the choice is not ours to make -- it's up to the developer.

If you want to start standarizing the extension names themselves, you open a Pandora box of internationalisation and localisation. On a Polish-only wiki, I will naturally want to use polish names for plugins. But domain names don't allow (by default) the use of characters like ą or ę. I believe that Chinese users would have even more trouble.

I like the idea of an "alt text", I think the same syntax that is used for images, <<plugin paramaters|alt text>> would be apropriate? Of course, the alt text would be probably somehow distinguished from the normal text (tinted background? red text? frame around it?). I wonder what should be rendered when the plugin is missing and there is no alt text specified -- displaying the parameters might be too much (although they would usually give some hint on the intended contents), maybe just the name of the missing plugin?

Yves, I don't quite understand this sentence:

If you accept name clashes, it isn't worth having it in the standard, and it isn't worth having alternative contents because you can't be sure you won't map to your plugin something else with the same name.

Can you please elaborate?

-- RadomirDopieralski, 2007-02-27

It's worth having a standard for alternative contents only if there are cases where they'll be used, i.e. if Creole markup is rendered by an engine which doesn't have the extension. How can an engine know it doesn't have the extension if it can't be sure about the name?

  • It doesn't have any extension. Ok, that may happen.
  • There are local conventions for that particular wiki and pages written for it remain there. But then there can be local conventions for extension syntax, no need to have a standard.
  • There could be some inter-wiki transfer, or pages which are published simultaneously on multiple wikis. Then there could be name clashes (for instance, many wiki engine developers will want a LaTeX plugin if it isn't supported at a more integrated level, so you'll have <<latex src="$a+1$>> , while others might prefer <<latex a+15>>. If you have alternative contents, how is it going
to help? Your plugin must recognize there is some weird syntax it doesn't like. But it isn't always possible. And pipes, for instance, are frequent in LaTeX.

(BTW, when do we accept multiline list items? I'm used to multiline paragraphs because it's easier to read and it's supported by Creole; but if you look at the source code of this very contribution, you'll see that my three list items look weird, because I had to remove line breaks to let wikicreole scan them correctly.)

-- YvesPiguet, 2007-02-27

I don't think name clashes are an issue, since they're internal to the wiki anyway - it might even make sense to use something like <<plugin 1>>. If you want to have a global namespace for these, you will also probably need to add things like version information as well, and then it gets messy.

The whole point of the "plugin" syntax is that it allows a wiki engine to use native extensions without losing them in the edit. I don't think the point of actually *moving* content from one wiki to another has ever really been their objective.

-- Janne Jalkanen

I fail to see how using a domain name prevents name clashes when moving between different wikis. After all it's pretty common that someone makes a neat plugin and then makes several versions for different wiki engines.

I think that the content of <<...>> should always be considered engine-specific and either escaped or converted when moving between wikis.

You are right about the pipe. What other solution there is? "->" maybe? Or maybe if we chnaged th order of the alt text and plugin: <<this is some plugin|pluginname some|paramaters|with pipes>>...

-- RadomirDopieralski, 2007-02-27

Wiki A has 'latex' mapped to 'unaffiliated.radomir.dopieralski.macro.latex'. So <<latex src="$a+1$>> does its thing. Wiki B has latex mapped to 'unaffiliated.jared.williams.macro.latex' and uses <<latex a+15>>. Both can import the others pages, as long as they know how each other maps the markup to actual plugin implementations.

There is also the question of how much markup to allow in the alt text, allowing all the markup would allow better approximation of the plugins output. Could also allow plugin nesting, so if the outermost fails, it attempt a fallback to the next innermost.

I think there are few situations when the alt text would be displayed


  • the plugin is missing.
  • the plugin fails due to some exceptional circumstance (ran out of file space for instance)

If the plugin is missing or fails, and is going to degrade the quality of outputted page, then there should be some distinction, maybe a red bar to the left, with link to a footnote explaining more.

In PHP there is an error/warning message supression operator, @

So whilst Plugin insertion failed: Could not find plugin latexPlugin insertion failed: Could not find plugin latex would generate a warning around the alt text, Plugin insertion failed: Could not find plugin latexPlugin insertion failed: Could not find plugin latex still would use the alt text, but it wouldn't be highlighted. A plugin having no output, cant impact quality so using no alt and @ would be silently ignored as far as the user is concerned.

-- JaredWilliams, 2007-02-27

From Gregor, originator of this proposal:

I think the debate whether plugins are uniquely identied by Java conventions is, ok, but its importance would be where two wiki engines do want to be interoperable or achieve automatic translation.

The point of an extension element is that Creole does not know or cares what is inside, except that the end-of-extension-box marker is not inside. The point is that providing an extension box stops screwing the rest of the content (especially by wiki-specific escaping requirements), and thus simplifies porting of content.

First as an aside: The extension box that I envision is not limited to plugins in a narrower sense, i.e. generating dynamic content. For example, I find JSPWikis abilitity to support custom CSS styles on Wiki text quite useful (much better than dozens of #red# etc. special markup) and would envision that inside an extension box as well. Or features like "invisible comments", etc. that some wikis support.

For dynamic plugins, I do like the idea of optionally supporting an "alt-text" or "cached-result" very much. It would be relevant for Creole to anticipate it, because Wiki-editor software may need to know about it.


introduces the small problem that the bar character may longer be part of the plugin. I would favor:

<<extension>>|<<optional cached-result>>

That is, multiple extension boxes separated by a bar without any other blanks refer to the first one, the second optionally containing a cached html-formatted result

The cached-result is automatically generated, so ease of typing is no concern here.

With regard to the discussion about URL/GUID plugin identifiers, what about:

<<extension>>|<<optional cached-result>>|<<optional url-based plugin identifier>>

Perhaps that would simplify the migration, and would be added where confusion may arise, but not required.

-- Gregor Hagedorn, 2007-02-27

I generally like this proposal, but have one problem with it. This markup is not NonDestructive -- that is, if something goes wrong (for instance, an user forgets to close it) it will "eat" a large chunk of the page, making it disappear without a trace.

Most of Creole's markup is confined to a single paragraph and displays the text that is inside. This markup has neither of the two "safety guards".

Is there a way this could be made "safer"?

-- Radomir Dopieralski, 2007-Mar-24

Good point, I had never thought about this. However, any feature desiring to support hidden editing comments as part of this (a common extension of wikis) would have this problem.

Would a clarification help, that

a) the extension element may not be nested (i.e. not only the closing ">>>" but aalso the opening "Plugin insertion failed: Could not find plugin arePlugin insertion failed: Could not find plugin are" is much rarer alone on a line. You could also use the difference to decide whether render the plugin result in a div or span.

-- RadomirDopieralski, 2007-May-30

YEP - need a generic extension proposal. Firstly a triple bracket like, { { { .... } } } and [[[ quote ]]] as I'm suggesting for a quotes implies that the content between the brackets is not parsed normally by the creole parser.

  • { { { - everything is accepted
  • [ [ [ - only formatting is parsed, whitespaces and newlines are displayed as is.
  • <<< - nothing in the brackets is part of the specification, except to say that the application must interpret it and/or reject it.

However, humans being humans, people are going to want to introduce their own code into Creole for those little things like font colours, sizes, table borders etc. etc.

If <<< ....>>> means "You've got to be kidding Creole doesn't have anything to say about text between those brakets.

<<SOMETHING>> might mean "not sure about that" and be reserved for an optional extension to the specification such as text colours. More specifically:-

<<#ABCDE#>> would have the meaning "optional code #ABCDE#"

-- Isonomia May 2008

I am personally against using << ... >> for Plugins. My main reason is that the double-angle-brackets are operators in this world (think C/C++/Java etc.)

Plugins should use the most rare syntax in order to allow a greater number of character combinations to be placed inside (as parameters). If << ... >> is used, the content between the brackets would not be able to use >>, making it impossible to use with C code inside. Well, escaping could be done for each >> but that would be tedious and would complicate the parser (not sure if escaping should even be possible inside the brackets for a plugin).

-- Mircea Bardac, August 2008

Do you have any example of such a plugin that accepts C code in it in any real wiki out there, or uses ">>" for other purposes?

The only thing that comes to my mind is syntax highlighting, but that could be built into the preformatted blocks.

-- RadomirDopieralski, 6 September 2008

I do not have an example of a plugin that accepts C code. All the C code I have seen was rendered in preformatted blocks, as you have mentioned. Then again, I haven't seen any wiki having a "plugin" markup.

I am considering using Creole and extending it in order to be able to custom render blocks. By "custom rendering" I mean <render this block only if "condition" is true>. These blocks can contain anything, including <<.

Also, how would someone build a "preformatted block with syntax highlight/line numbering" in Creole?. I am thinking that <<syntax=C ...>> could be used for this, because there is no support in the default markup. That means the contents of the tag would have to be somehow escaped if << is in the block.

This is the main reason for trying to have something as uncommon as possible for the Plugin markup. You can't know exactly what needs to be passed to a plugin and the plugin markup should be as uncommon as possible (maybe even more verbose). This is probably one of the problems for HTML templating systems. There will always be conflicts and escaping would be needed, but I guess the need for this could be decreased.

As for the implementation, I believe it should be like a block markup (HintsOnExtending) to cover all possible uses of the Plugin. The 3-characters block markup would also decrease the chance of collisions. I think the specification should also include a way of defining the plugin name inside the markup - would definitely help the developer and make the plugin markup look clean across implementations - maybe something like $$$plugin:...$$$ - $ was chosen randomly from the list.

-- Mircea Bardac, 7 September 2008

Add new attachment

Only authorized users are allowed to upload new attachments.

« This page (revision-36) was last changed on 18-Sep-2008 16:30 by