JSPWiki
  1. JSPWiki
  2. JSPWIKI-570

Cannot use another MarkupParser - hardcoded references to RenderingManager and JSPWikiMarkupParser

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 2.8.2
    • Fix Version/s: FutureVersion
    • Component/s: Core & storage
    • Labels:
      None

      Description

      I'm playing a little with JSPWiki and decided to try different markup syntax to learn a bit more. To do so I have to inherit from RenderingManager and implement another MarkupParser. WikiEngine does good job instantiating RenderingManager:

      m_renderingManager  = (RenderingManager)   ClassUtil.getMappedObject(RenderingManager.class.getName());

      but src/webdocs/templates/default/editors/FCK.jsp does it directly:

      RenderingManager renderingManager = new RenderingManager();

      while it should get help from WikiEngine:

      RenderingManager renderingManager = engine.getRenderingManager();

      or (it new instance is required) call getMappetObject itself.

      There are also some problems with JSPWikiMarkupParser:

      • direct calls or references to static members getImagePatterns, isExternalLink, makeError - (not a big problem for me)
      • private members - some of them would be useful for inherited parser (for example no access to build DOM: m_plainTextBuf, pushElement and related, fillBuffer (of course I can copy-and-paste JSPWikiMarkupParser rather than inherit from it)
      • direct instantiation in src/com/ecyrd/jspwiki/plugin/TableOfContents.java
        JSPWikiMarkupParser parser = new JSPWikiMarkupParser( context, ...
                    parser.addHeadingListener( this );
                    parser.parse();
        

        this looks like a bigger problem, because TableOfContents:

        • does its own parsing (so parsing is done two times) and also (ok this is just performance),
        • does this with directly instantiated JSPWikiMarkupParser (so mine is not called what means I can't change header indicators)

      Of course for my purpose I will do required corrections. The question is are you gays going to work on it?, is it also a problem in 3.0 ? Should I prepare and publish a patch?

        Activity

        Hide
        Goran Karlic added a comment -

        Do not expect many gays to work on it

        Show
        Goran Karlic added a comment - Do not expect many gays to work on it
        Hide
        Harry Metske added a comment -

        If you expect gays to work on it, I won't, but you probably mean guys

        Show
        Harry Metske added a comment - If you expect gays to work on it, I won't, but you probably mean guys
        Hide
        Goran Karlic added a comment -

        Harry, please do consider that "A" and "U" are rather apart on a typical keyboard.

        Show
        Goran Karlic added a comment - Harry, please do consider that "A" and "U" are rather apart on a typical keyboard.
        Hide
        Harry Metske added a comment -

        Piotr, I don't see why we shouldn't fix at least some of your issues, but I'd rather have Janne, Dirk or Andrew have a look at it.

        Show
        Harry Metske added a comment - Piotr, I don't see why we shouldn't fix at least some of your issues, but I'd rather have Janne, Dirk or Andrew have a look at it.
        Hide
        Piotr Tarnowski added a comment -

        What's a shame. I'm sorry for misspelling hope nobody feels offended.
        At least I got some response
        Should I prepare patch for 2.8.2 or 3.0? Probably both but if a lot of changes is planned for 3.0 this may not have sense.

        Show
        Piotr Tarnowski added a comment - What's a shame. I'm sorry for misspelling hope nobody feels offended. At least I got some response Should I prepare patch for 2.8.2 or 3.0? Probably both but if a lot of changes is planned for 3.0 this may not have sense.
        Hide
        Janne Jalkanen added a comment -

        Actually, this is a valuable refactoring that I would like to have as a part of 3.x, but I'd like to go a bit farther than that and make sure that there are no deep dependencies between MarkupParsers and the rest of the code.

        This is, in a sense, a duplicate of JSPWIKI-120, in fact. (Or at least linked strongly.)

        But it's a good start; can you propose a patch against the current 3.0 svn trunk? Preferably separate patches; some patches might be doable in 2.8 as well.

        Show
        Janne Jalkanen added a comment - Actually, this is a valuable refactoring that I would like to have as a part of 3.x, but I'd like to go a bit farther than that and make sure that there are no deep dependencies between MarkupParsers and the rest of the code. This is, in a sense, a duplicate of JSPWIKI-120 , in fact. (Or at least linked strongly.) But it's a good start; can you propose a patch against the current 3.0 svn trunk? Preferably separate patches; some patches might be doable in 2.8 as well.
        Hide
        Harry Metske added a comment -

        Piotr,

        it's a long time ago, but can we still expect patches ?
        If not, I'd like to close this issue.

        Show
        Harry Metske added a comment - Piotr, it's a long time ago, but can we still expect patches ? If not, I'd like to close this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Piotr Tarnowski
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development