You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Piotr Tarnowski (JIRA)" <ji...@apache.org> on 2009/06/05 18:28:07 UTC
[jira] Created: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
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.
[jira] Updated: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Harry Metske (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Harry Metske updated JSPWIKI-570:
---------------------------------
Fix Version/s: FutureVersion
> 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
> Fix For: FutureVersion
>
>
> 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Goran Karlic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716665#action_12716665 ]
Goran Karlic commented on JSPWIKI-570:
--------------------------------------
Do not expect many gays to work on it ;-)
> 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Harry Metske (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716669#action_12716669 ]
Harry Metske commented on JSPWIKI-570:
--------------------------------------
If you expect gays to work on it, I won't, but you probably mean guys :-)
> 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Harry Metske (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Harry Metske (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716681#action_12716681 ]
Harry Metske commented on JSPWIKI-570:
--------------------------------------
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.
> 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Piotr Tarnowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716766#action_12716766 ]
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: 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Janne Jalkanen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716896#action_12716896 ]
Janne Jalkanen commented on JSPWIKI-570:
----------------------------------------
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.
> 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.
[jira] Commented: (JSPWIKI-570) Cannot use another MarkupParser -
hardcoded references to RenderingManager and JSPWikiMarkupParser
Posted by "Goran Karlic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716673#action_12716673 ]
Goran Karlic commented on JSPWIKI-570:
--------------------------------------
Harry, please do consider that "A" and "U" are rather apart on a typical keyboard.
> 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.