===== Wanted Wikka formatters =====
{{lastedit show="3"}}>>See also:
~-AdvancedFormatter
~-WikkaExtensibleMarkup
~-PseudoFormatters
~-LinkTails
~-AcronymFormatter
>>::c::

I created this page to list proposals about [[Docs:FormatterInfo 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<<::c::
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 ""<a name="Section"></a>"" 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]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-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 ##&amp;amp;##, not a single ##&amp;## 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 ##&amp;## which is clearly incorrect. --JW
~~~~~&Just a small point ##&amp;## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&amp;## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&amp;## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--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;)
%%(php)
		static $trigger_sup = 0;
		static $trigger_sub = 0;
%%

add after 	if ($trigger_bold % 2) echo('</strong>');
%%(php)
			if ($trigger_sup % 2) echo '</sup>';
			if ($trigger_sub % 2) echo '</sub>';
%%

change the long line a little below to:
%%(php)
			$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%

add after the ""//center"" block:
%%(php)
		// higher text
		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:
%%(php)
	"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|&pound;&pound;|&yen;&yen;|\v\v|\^\^|\+\+|__|<|>|\/\/|".	# Wiki markup
%%
----
CategoryDevelopmentFormatters