(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

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 86.121.181.221  

This page was created on 26-Feb-2007 20:41 by YvesPiguet

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 264 added 18 lines
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
Version Date Modified Size Author Changes ... Change note
36 18-Sep-2008 16:30 23.608 kB 86.121.181.221 to previous
35 07-Sep-2008 15:33 23.603 kB 86.121.181.74 to previous | to last
34 06-Sep-2008 00:50 21.895 kB RadomirDopieralski to previous | to last any example of plugin using >>?
33 31-Aug-2008 00:24 21.597 kB 86.121.181.74 to previous | to last
32 16-May-2008 17:31 20.927 kB Isonomia to previous | to last
31 28-Oct-2007 09:20 19.858 kB RadomirDopieralski to previous | to last restore
30 27-Oct-2007 21:46 19.87 kB 140.128.20.205 to previous | to last
29 26-Sep-2007 09:43 19.858 kB ChuckSmith to previous | to last restore
28 26-Sep-2007 01:25 19.902 kB 63.241.9.240 to previous | to last
27 26-Sep-2007 01:25 19.89 kB 195.246.155.219 to previous | to last
26 30-May-2007 17:04 19.858 kB RadomirDopieralski to previous | to last div & span
25 30-May-2007 16:05 19.637 kB YvesPiguet to previous | to last inline/block plugin
24 16-Apr-2007 01:10 19.204 kB 85.221.141.46 to previous | to last when to use text tags?
23 13-Apr-2007 22:53 18.408 kB 77.128.29.49 to previous | to last Balance design guidance
22 12-Apr-2007 01:53 18.033 kB 84.150.9.42 to previous | to last
21 11-Apr-2007 23:54 17.158 kB RadomirDopieralski to previous | to last reinvent the wheel
« This page (revision-36) was last changed on 18-Sep-2008 16:30 by 86.121.181.221