incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piotr Tarnowski (JIRA)" <>
Subject [jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser - hardcoded references to RenderingManager and JSPWikiMarkupParser
Date Fri, 05 Jun 2009 22:02:07 GMT


Piotr Tarnowski commented on JSPWIKI-570:

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.

> Cannot use another MarkupParser - hardcoded references to RenderingManager and JSPWikiMarkupParser
> --------------------------------------------------------------------------------------------------
>                 Key: JSPWIKI-570
>                 URL:
>             Project: JSPWiki
>          Issue Type: Bug
>          Components: Core & storage
>    Affects Versions: 2.8.2
>            Reporter: Piotr Tarnowski
>            Priority: Trivial
> 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}}:
> {code:java}m_renderingManager  = (RenderingManager)   ClassUtil.getMappedObject(RenderingManager.class.getName());{code}
> but {{src/webdocs/templates/default/editors/FCK.jsp}} does it directly:
> {code:java}RenderingManager renderingManager = new RenderingManager();{code}
> while it should get help from {{WikiEngine}}:
> {code:java}RenderingManager renderingManager = engine.getRenderingManager();{code}
> 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/}} {code:java}
> JSPWikiMarkupParser parser = new JSPWikiMarkupParser( context, ...
>             parser.addHeadingListener( this );
>             parser.parse();
> {code} 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?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message