Wanted Wikka formatters
I created this page to list proposals about formatters that might be implemented in future Wikka releases.
Feel free to add your ideas/comments.
Preformatter
Modifies data before it goes into the database, adding signatures, typographical sharpness and ensuring all ampersands are properly escaped.See PreFormatter
-- IanAndolina
- While I agree on "preformatting" things like signatures and possibly "typographical sharpness", escaping ampersands before test is stored will make source harder to edit for people who don't know HTML - unless you also are going to 'unescape' each time the edit form is displayed. It's simpler and more logical to 'educate' the formatter to escape this special character as it's already doing for < and >. I've already written (and tested) the code to do this (excluding entities); this will probably become part of the next (1.1.6.1) release. -- JavaWoman
Inline comments formatting
See InlineCommentFormatter-- DarTar
User-oriented formatters
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: footnotes and tables of content. (see below the discussion on named anchors)- See also the TableofcontentsAction page (work-in-progress!). --JavaWoman
Table formatters
A good wikka syntax for tabular data is IMO one of the top priorities for future Wikka development. Some WikkaTables ideas have already been suggested.More <div> formatters
I find quite limiting that Wikka only includes formatters for flush-left and flush-right divs. I would like to see a larger set of formatters, that - in association with CSS selectors - might be used to output absolute-positioned divs, bordered divs, divs with different degrees of padding/margin etc.- I needed this on my site so I made this InlineDivFormatting little hack. It allows some basic controls, but is inline so you get to use all the other parts of the wikka markups
System formatters
See: WikkaMenulets
It might be interesting - in the spirit of the {{lastedit}} and {{version}} action - to have a set of formatters for printing specific system-related information (GmBowen has also recently suggested something in this lines). I am not sure, though, whether this function should be implemented as a set formatters or as an action.
- In the same spirit, I just created a HighlighterAction {{highlighter}} action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman
In page links
It would be nice to have in page linking so you can jump directly to a section of a page in the format PageName#Section you could then reuse the Wacko {{ancher}} action to inset the code.- Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
- We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
- See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman
A better formatter for forced internal links
I think that the current forced link formatter should be improved to allow GET parameters, anchors and titles to be parsed as part of valid internal links.
For example it would be nice if we could not only use forced links like:
[[HomePage Internal forced link]]
or
[[http://www.google.com External forced link]]
but also the following:- Forced internal link with URL parameter
[[HomePage (? "par1=ba,par2=bo") Internal forced link]]
- Forced internal link with anchor
[[HomePage (# "this") Internal forced link]]
=> http://wikka.jsnx.com/HomePage#this
- Forced internal link with Title
[[HomePage (§ "This is a link to the HomePage") Internal forced link]]
But I don't have a clue on how to modify the current formatter to send to the Link() function all this stuff.
- I like this idea very much, especially being able to add a title. A few remarks, no particular order:
- The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
- Good point --DarTar
- Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
- Good point as well --DarTar
- How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
- To combine query parameters they should be separated with &, not a single & which is invalid in HTML
- This has to be done by the formatter, not by the user. -- DarTar
- Ah, but when you give an example of what it should result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single & which is clearly incorrect. --JW
- Just a small point & is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
- Sorry, but no: A 'bare' & is just as invalid in HTML as it is in XHTML: the (unescaped) & is seen as the start of an entity reference in all versions of HTML. --JavaWoman
- My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be WikiName#link!"title text". I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. {{action foo="bar"}}. Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.
Might be relevant for the present discussion: MeatBall:CleanLinking
-- DarTar
Superscript annd subscript (<sup>/<sub>)
Ticket:160 (text higher or lower in the line than normal)There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.
- Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)
Anyway, changes necessary to formatters/wakka.php (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
static $trigger_sup = 0;
static $trigger_sub = 0;
static $trigger_sub = 0;
add after if ($trigger_bold % 2) echo('</strong>');
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
if ($trigger_sub % 2) echo '</sub>';
change the long line a little below to:
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
add after the //center block:
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
- I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
- Agreed and changed. --NilsLindenberg
and finally change the line with #Wiki Markup (near the end) to:
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
CategoryDevelopmentFormatters
