1 Reply Latest reply on Nov 11, 2004 11:04 AM by theute

    Stack parser / Formatter

    theute

      The formatter consists in two parts, the parsing and the rendering.

      So to me, a formatter consist in a parser (to parse BBCode, HTML, Wiki...) plus a renderer (HTML, plain text, Flash...)

      Some people may want to allow 2 parsers at once (like this forum) so you could write code like:

       Hey this is <b>HTML<b>, but wait a minute here is some BBCode.
      


      (oups by previewing this thread i realize that the BBCode is interpreted in code sections, is it what we want ? It can be cool as it allows to highlight some part of the code)

      In a perfect world we would just go through parsers one after the other but it's not that easy and some languages may collide.
      So if i am not wrong HTML+BBCode could be consider as a different parser so here are some parsers we could have:

      HTML
      BBCode
      HTML+BBCode
      Wiki

      Plus we have some filters, there are some already, for linebreak and special entities:
      - A line break depends on the renderer (think HTML and plain text)
      - A special entity also depends on the renderer (think HTML and plain text)
      We may want to add other filters like:
      - Bad word filter for all the damn f*****
      - spell correct filter

      So now my new definition of a formatter is 1 parser, 1 renderer and N filters

      In Nukes 2 it needs to be more "configurable" for each portlet. For example a Wiki portlet may want to accept only Wiki code and a Forum only BBCode but a HTML module would accept both at the same time. (Wiki ad the forum would use the HTML rendered for screen output while they would use plain text for email for example) and so would use the HTML+BBCode Parser

      We also need to configure the different accepted tokens (like only bold and italic for HTML)

      I thought about 3 levels to configure this:
      Component level to define the available formatters and the default formatters used by any portlet (or other component)
      Portlet level to override the portal level information to be specific to this portlet.
      User Level, if a portlet developer wants he should allow the user to pick among the available formatters which one he wants. (like on Slashdot)

      I think it should be done in the XML configuration files:
      We already have:
      standard-nukes.xml to write down component default
      We have portlet.xml defined by the portlet specifications, as we would extend it maybe we could add another configuration file:
      nukes-portlet.xml to define Nukes Portlets.

      Any thoughts ? (I know Chase had some, but he got trapped by a job i think)