incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harry Metske (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser - hardcoded references to RenderingManager and JSPWikiMarkupParser
Date Sat, 01 May 2010 16:44:55 GMT

    [ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863027#action_12863027
] 

Harry Metske commented on JSPWIKI-570:
--------------------------------------

Piotr,

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

> Cannot use another MarkupParser - hardcoded references to RenderingManager and JSPWikiMarkupParser
> --------------------------------------------------------------------------------------------------
>
>                 Key: JSPWIKI-570
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-570
>             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/TableOfContents.java}} {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.


Mime
View raw message