Revision [3637]

This is an old revision of WantedFormatters made by DarTar on 2004-12-24 08:55:23.

 

Wanted Wikka formatters

Last edited by DarTar:
Adding further ideas
Fri, 24 Dec 2004 08:55 UTC [diff]


I create this page to list proposals about FormatterInfo formatters that might be implemented in future Wikka releases.
Feel free to add your ideas/comments.

Inline comments formatting

We currently use a combination of indentation and notes highlighting to mark inline comments, which sometimes produces layout inconsistencies and makes the discussion difficult to follow. I'd like to introduce a dedicated syntax for inline comments, on the model of DocuWiki (scroll to the bottom of the page).
-- 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)

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.

System formatters

 

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 spitit, 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

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


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:

[[HomePage (? "par1=ba,par2=bo") Internal forced link]]
[[HomePage (# "this") Internal forced link]]
[[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:

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.

-- DarTar

Might be relevant for the present discussion: MeatBall:CleanLinking



CategoryDevelopment
There are 7 comments on this page. [Show comments]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki