done

• added span and div methods to formatter.base (default implementation: return "")

• cleaned up formatter api (DeronMeranda's patch)

• made li p p possible aka dont close/reopen on same level
• opt. " . " markup for ul type none - fixes same level ul-none vs. paragraph merge problem

ideas

• JohannesBerg/ParserFormatterCommunication

old stuff below

Planned

1.3

• Allow markup for GUI
  • make parser reusable

  • change handling of highlighting -- how ?

  • reduce independencies of objects (parser, page, formatter, request, ...)
• output escaping needs to be moved into the formatter, cause only the formatter knows how to escape...
  • currently text_html.text calls wikiutil.escape and all parsers call wikiutil.escape. This results in double escaping.

  • fixed in moin--colorize--1.3. See CodeBlockColorizer. -- OliverGraf 2004-07-23 07:06:17

1.3 or later

• move formatting to formatter (and out of the parser)

  • concrete examples?

• make all formatter methods get a "on" parameter (right call order)

Reduce dependencies

The parsers by now are not reusable.

class Parser:
    def __init__(self, raw, request, **kw):
    def format(self, formatter):

class Macro:
    def __init__(self, parser):

This means it is not possible to feed some new input to an existing Parser. It would of cause be possible to instantiate a new one, but this one would not be in the same state and could break the HTML more easily.

For using the wiki parser for (parts of) the user interface it would be even more important to reuse the parser as instantiation of a parser is relative expensive.

New interface:

class Parser:
    def __init__(self, request=None, **kw):
    def format(self, text, formatter)

class Macro:
    def __init__(self, request)

append Page object to request.

Use of Formatter

Lots of macros and formatters do not use the formatter in a proper way. Some do not even use the formatter but only return HTML. Most others return formatter.rawHTML(some_stuff) which is not much better.

see ApplyingFormatters

• make all processors and macros at least use formatter.rawHTML
• replace formatter.rawHTML by the proper calls to the formatter to allow non-HTML formatters to produce correct output

Open questions:

• what about HTML features not yet supported by the formatter (especially forms)?

• shouldn't macros and processors be able to produce WikiMarkup and call a wiki parser easily?

• what about using request.write() instead of returning a string (default for processors, sometimes used in macros)?

What exactly is formatting?

By now the formatter just replaces function calls by HTML tags. Highlevel formatting like inserting the icons in front of the InterWiki links is done by the parser (as of 1.5, this is done by CSS - are there other examples?). If we want to use non-HTML formatters like XML, Latex, other wikimarkup, ... all formatting must be moved to the formatter.

Additional formatter features

• generate anchors for headings

add more

DOM formatter

I started a first try writing a formatter generating a DOM tree. Problems:

• Formatter is not called in the correct order

  • remove text parameters from the following methods

    • .lang

    • .sysmessage

    • .heading

    • .url

      • remove automatic <img> link support

    • .anchorlink

    • .code_token

• new formatter features:

  • .interwikilink

  • .icon

• move highlighting into the formatter

Check formatters

• base

• text/xml - generally not in a good state

• text/python

  • interwikilink is still static

• text/plain

• text/html

• dom/xml

Macros

The macro object wikimacro.py gets a parser object in its constructor. Because of this it is very difficult to use the macros from arbitrary code. But macros don't need the parser: neither can they use the parser for parsing (see above) nor could they use the parser if it isn't the wiki parser.

It would be much better if the macro object would get the request object and a formatter.

HTML in MoinMoin Code

By now there is a lot of HTML code distributed over nearly all parts of MoinMoin. At least some of them could be replaced by formatter calls (complicated and error prone) or wikimarkup (expensive if not cached). The most obvious features the formatter is missing by now is:

• Forms
  • form tag
  • input
  • textarea
• colorized source code (used by processors, parsers)

  • the markup of the code tokens via <span>s and predefined styles. (formatter.span added in moin--refactor--1.5)

  • new method, so any formatter can generate something useful.

    formatter.code_area(1)
    for token in code:
      formatter.code_token(token.string, token.type)
      if eol:
        formatter.code_line(1)
    formatter.code_area(0)

  • this was implemented in CodeBlockColorizer and is already inside moin--main--1.3

Please add more.

Discussion

While working on themes, I started an /DomLikeHtmlFormater . I'm not sure its better then current way theme write their code, but it avoids all the "start tag" "close tag" problems, since you just create elements and add child elements in them. -- NirSoffer

In 1.3.3 the base formatter still contains HTML specific output, e.g. for images - this should be moved to the text_html formatter -- RobertSeeger 2005-02-02 18:10:58 (iirc, also done in moin--refactor--1.5 branch)

Semantic Formats

Would be nice to add to the formatter API methods to represent some semantic data, like formatter.author('WilliamShakespear') or formatter.item/section(on) - for items in a feed

The text/html formatter could ignore these methods - or format them however Moin does currently - with section headers, etc.

Formatters for other SemanticFormats might represent this data specially - for instance an RDF formatter might represent the author in an author XML tag. An RSS formatter might represent items/sections as appropriate RSS feed items

With this extension to the formatter API, the RecentChanges code might generate multiple SemanticFormats from the same code

The DublinCore data would be a good start -- JackBates 2006-01-26 23:53:28