Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 310611

Summary:

Improve HTML rendering for Confluence markup language (e.g. table borders)

Product:

z_Archived

Reporter:

Wojciech Seliga <wseliga>

Component:

Mylyn

Assignee:

Torkild Resheim <torkildr>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

enhancement

Priority:

CC:

torkildr

Version:

unspecified

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Adding more info (CSS classes and additional wrappers) to built document	none
sample CSS used on the client side	none

Description Wojciech Seliga

2010-04-27 07:56:19 EDT

Build Identifier: 

We use WikiText to render wiki syntax for Atlassian JIRA and Crucible (in Atlassian Connector for Eclipse).
Unfortunately there are a lot of visual differences between HTML rendered by WikiText and wiki (Confluence) renderer used by JIRA and Crucible web UI (e.g. missing table borders, colours for headers, panels, spacing, etc.).

I took the first stop to address it. As it's my first direct patch submission to Mylyn, please be patient. I am pretty sure that a few iterations may be required to have it in acceptable shape.

The idea: re-use CSS (as much as we can) used by web UI of Atlassian products.
Then, if we inject appropriate CSS classes into created document (blocks), we'll have HTML rendering just done correctly without any changes.

Then the client can use an implementation of AbstractRenderingEngine which uses HtmlDocumentBuilder with injected CSS file.

I cannot see any existing unit tests for Confluence WikiText, so I am not adding anything new there.

I wonder what you think about this approach.
Currently it works fine in my workspace and I have much nicer (and more complete) HTML preview of wiki syntax than before.

Reproducible: Always

Comment 1 Wojciech Seliga

2010-04-27 08:06:16 EDT

Created attachment 166183 [details]
Adding more info (CSS classes and additional wrappers) to built document

first approach

Comment 2 Wojciech Seliga

2010-04-27 08:13:04 EDT

Created attachment 166185 [details]
sample CSS used on the client side

Sample CSS which I set in the client code in following way.

myRichTextEditor.setRenderingEngine(new AbstractRenderingEngine() {

	@Override
	public String renderAsHtml(TaskRepository repository, String text, IProgressMonitor monitor)
			throws CoreException {

		final Reader reader = getCrucibleDefaultStylesheetContent();
		final HtmlDocumentBuilder.Stylesheet styleSheet = new HtmlDocumentBuilder.Stylesheet(reader);
		try {
			markupParser.setMarkupLanguage(markupLanguage);
			final StringWriter writer = new StringWriter();
			final HtmlDocumentBuilder builder = new HtmlDocumentBuilder(writer) {
				public void beginDocument() {
					super.beginDocument();
					beginBlock(BlockType.DIV, new Attributes());
					Attributes attributes = new Attributes();
					attributes.setCssClass("markup");
					beginBlock(BlockType.DIV, attributes);
				}

				@Override
				public void endDocument() {
					endBlock();
					endBlock();
					super.endDocument();
				}

			};
			builder.addCssStylesheet(styleSheet);
			markupParser.setBuilder(builder);

			markupParser.parse(text);
			return writer.toString();
		} finally {
			try {
				reader.close();
			} catch (IOException e) {
				StatusHandler.log(new Status(IStatus.WARNING, CrucibleUiPlugin.PLUGIN_ID,
						"Cannot close CSS reader"));
			}
		}
	}
});


This CSS is directly taken from CSS file used by web UI (with removed irrelevant sections). Note additional CSS selectors, which made me wrap some content.
I wanted to avoid modifying this CSS, to make easier in the future keeping it in sync with web UI

Comment 3 David Green

2010-04-29 13:40:27 EDT

Thanks for the bug and patch.  It's a great start.

Some things I'd like to see:
* there should be no need to subclass HtmlDocumentBuilder: all of this should occur in the markup language.
* unit tests must be provided to verify that all of your changes work.  See the org.eclipse.mylyn.wikitext.tests bundle for examples, specifically @org.eclipse.mylyn.wikitext.confluence.core.ConfluenceLanguageTest@
** your changes likely break some of the existing tests, so your patch should update those tests.

Great work, I look forward to the next iteration.

Comment 4 Wojciech Seliga

2010-05-11 06:18:58 EDT

Thanks David,

I did not notice ConfluenceLanguageTest, I incorrectly assumed that Confluence tests would be in some Confluence specific bundle.
I'll add them and fix broken tests.

Comment 5 David Green

2010-05-11 19:42:32 EDT

To keep things simple we have all WikiText tests in a single bundle.

Comment 6 Torkild Resheim

2012-12-05 05:28:15 EST

With Atlassian removing the wiki markup format in their Confluence 4.0 release I think continuing supporting Confluence is a waste of time. Proposing to resolve as WONTFIX.

http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/

Comment 7 David Green

2012-12-06 23:19:07 EST

Thanks for the suggestion Torkild.  Since this affects many bugs and support for Confluence wiki markup in general, I've opened up the discussion on the mylyn-docs-dev mailing list.

Comment 8 Torkild Resheim

2013-06-07 14:18:34 EDT

*** Bug 336905 has been marked as a duplicate of this bug. ***

Comment 9 David Green

2013-08-02 12:44:02 EDT

Closed as part of backlog clean-up.  Please re-open if you'd like to see this revisited, perhaps with a contribution.