Community
Participate
Working Groups
Created attachment 196254 [details] Patch for 1.4 RC1 org.eclipse.rap.rwt RAP/RWT is a wonderful web 2.0 toolkit especially because it complements scout's single sourcing concept with multiple ui facades. However RWT is positioned between to paradigms, "SWT" and "Web2.0". This results in conflicts regarding closed/limited world of SWT compared with styled and markup enriched web 2.0 world. Regarding the ScoutRwt ui layer we currently face major limitation in the SWT/RWT Table. We lack of mutli-line table headers, multi-line table cells and html support for simple cell text styling / decoration. As I understand that the SWT api may not be extended or changed I suggest using extension adapters to add RWT-specific and Web2.0 supporting functionality to widgets. In Swing rendering a table cell or a table header with html styled text is done by simply enclosing the cell text with the html tag: <html>Hello World</html> This marker is interpreted by the ui factory to render the text not as plain text but as styled text. The attached patch adds the basic "rich" table functionality known from other web2.0 frameworks and swing to RWT. It consists of the following parts on "org.eclipse.rap.rwt": 1) adding ITableColumnExtensionAdapter to TableColumn with property verticalAlignment. horizontal alignment already exists, this verticalAlignment completes the css support. 2) adding ITableExtensionAdapter to Table with property itemHeight. This supports for easy setting the text height of all table rows to a value different than one font size (for example 60) 3) adding HtmlTextUtil for basic handling of marked-text-to-html, html-to-plain and isHtmlMarker functionality. And it consists of the following parts on "org.eclipse.rap.rwt.q07": 4) adding handling for verticalAligmnment to TableColumnLCA and TableLCAUtil 5) adding switch to ItemLCAUtil.writeText to pass-through html-styled text without encoding 6) adding switch to TableItemLCA.writeTexts to pass-through html-styled text without encoding 7) adapting TableColumn.js and TableItem.js 8) (rebuilding client.js)
Created attachment 196255 [details] Patch for 1.4 RC1 org.eclipse.rap.rwt.q07
Created attachment 196257 [details] Patch (2) for 1.4 RC1 org.eclipse.rap.rwt
Created attachment 196258 [details] Patch (2) for 1.4 RC1 org.eclipse.rap.rwt.q07
Created attachment 196327 [details] Patch for 1.4 RC1 org.eclipse.rap.rwt.q07
Created attachment 196328 [details] Patch for 1.4 RC1 org.eclipse.rap.rwt
This bug is a blocker for our projects therefore I increased the importance of this bug. Could you please have a look at the attached patches and or start a discussion about the issue.
This feature has a high priority for us, but we did not come around to work on it yet. You can expect some progress on this issue in the next few days.
First off, thanks for your work on this. I really see the need for features towards Web 2.0 that are not covered by the SWT API. As Tim mentioned, we're also thinking about ways to extend RAP to those cases. Enhancing the SWT API using adapters may be a reasonable way in this case. However, I think there are many different aspects to consider. As an example, how would markup affect the text size determination? Would TableLayouts still work reliably? Which subset of HTML tags should be supported? If we add support for markup in the Table, we'll have to add similar features for other widgets too, so we should think about a general adapter type. And so on... Adding new features is always a commitment, and we'll have to take our time to come to a sustainable solution. We're currently focused on the Indigo release and won't have the time to give detailed feedback to your patches, but we'll come back to them. Since the bug title sounds like an umbrella bug for a number of suggested enhancements, I would suggest to open dependent "sub-bugs" for each enhancement. This will keep the discussion clearer than and let us work on single sub-items step-by-step. I noticed that the patches do not apply to the workspace root. Could you try to change this as this would make it easier to apply them using Eclipse. Just select "Workspace" under "Patch Root" in the Eclipse "Create Patch" wizard. (In reply to comment #6) > This bug is a blocker for our projects therefore I increased the importance of > this bug. I reverted it to enhancement, because this bug does not report a defect of an existing feature but it requests a new feature. Since bugs and enhancement requests have to be handled differently, our policy is to set all enhancement requests to "enhancement".
Thanks Ralf. >> Since the bug title sounds like an umbrella bug for ... I agree >> If we add support for markup in the Table, we'll have to add similar features for other widgets too... I agree, mainly this includes table cell, table header, tree cell, label (styled label?) >> I reverted it to enhancement, because... I agree >> I noticed that the patches do not apply to the workspace root I will attach a new one, certainly.
Created attachment 196963 [details] Patch on org.eclipse.rap.rwt and ...rwt.q07
*** Bug 320742 has been marked as a duplicate of this bug. ***
Basic support for markup in TableItem#setText() has been added. It must be enabled by calling setData() with Table.ENABLE_RICH_TEXT and a value of Boolean.TRUE. See the JavaDoc there for further information. Parsing, size-calculation and rendering the markup can be found in RichTextParser, RichTextUtil, RichTextToHtmlTransformer so that it can be reused for the Tree. All API is preliminary and will likely change once we came to a conclusion on how to handle RWT-specific extensions to SWT in general. Changes are in CVS HEAD
Changed summary to better reflect the purpose of this bug. Multi-line column headers are covered by bug 341812
Brilliant. Here is how i tested it: table = new Table( parent, style ); table.setData( Table.ENABLE_RICH_TEXT, Boolean.TRUE ); table.setData( Table.ITEM_HEIGHT, new Integer( 35 ) ); ... item.setText( i, "<html>Item <br/><font name = \"courier\" height=\"15\"> " + index + "-" + i + "</font></html>"); My two cents: - So the input is a very simple pseudo-html (is it made-up?), so it's not relevant how the browser would parse it. The output html however uses the outdated/deprecated "<font>" tag, we should use the more flexible "<span>" with css intead. - Did not try inserting an image yet, nut sure how to do it. In any case it might be a good idea to be able to give the size programatially, so the content does not jump when its loaded. - The additional div wrapping the html (line-height:normal) should not be needed. If you can give me a hint what exaclty goes wrong without it, i might be able to find a fix for that. - Bug: I cant select a row with a mouseclick when i click directly on the cell-content. Unless you know why, i will also look into that. - Possible future enhancements: change color and alignment.
(In reply to comment #14) > [ ... ] > My two cents: > - So the input is a very simple pseudo-html (is it made-up?), so it's not the pseudo-html is meant to be a (tiny) subset of HTML wherever possible > relevant how the browser would parse it. The output html however uses the > outdated/deprecated "<font>" tag, we should use the more flexible "<span>" with > css intead. agreed > - Did not try inserting an image yet, nut sure how to do it. In any case it > might be a good idea to be able to give the size programatially, so the content > does not jump when its loaded. The JavaDoc for Table#ENABLE_RICH_TEXT explains how to display images. Please let me know if there is something missing or unclear. I will add the width and height attributes to the <img> element that is sent to the browser. > - The additional div wrapping the html (line-height:normal) should not be > needed. If you can give me a hint what exaclty goes wrong without it, i might be > able to find a fix for that. The div which represents the table cell sets the line-height to the height of the TableItem. If I wouldn't 'reset' the line-height in the extra div, multiple lines wouldn't work. Just remove the style attribute from the extra div and you will see. If there is a more decent solution to this, I would be gald to apply it. > - Bug: I cant select a row with a mouseclick when i click directly on the > cell-content. Unless you know why, i will also look into that. That would be great, thanks! > - Possible future enhancements: change color and alignment. Sure, <b> and <i> are also missing.
The size of images is now rendered to the client. Changes are in CVS HEAD
(In reply to comment #14) > [ ... ] > - Bug: I cant select a row with a mouseclick when i click directly on the > cell-content. Unless you know why, i will also look into that. Selection works in Firefox 5 and IE 9, but not in Chrome 12
Okay, after some (and with "some" i mean a lot) research on the Chrome issue i have to give up for now. Heres what i know for now: - The "mousedown" does not get fired when clicking the cells content. - The cell itself can be clicked below the content (if there is space) - It happens only if there are html-tags in the content - It works fine with the exact same html-code on a static page (w/o JS) - It's not related to innerHTML, document.createElement has the same issue - It's not a specific html-tag either, though this is not yet fully tested - It's also not the lineHeight, zIndex, align or whitespace attribute. For now i can only assume that its somehow related to when/how the cell-node is created/inserted/rendered. As for the lineheight issue: Its complicated in that this attribute is needed for vertical alignment with non-html content to work. Of course one could configure the lineheight depending on whether html-content is present or not, but the best way would be to solve this issue when implementing vertical alignment for cells with html-content (which is going to be complicated thanks to IE.)
Fixed bug 353204 which should solve the selection issue.
I don't see the need to calculate the width of the rich text in a column. The height is sufficient. I'm attaching a patch written by Ivan Motsch. This solves the desired enhancement with an simple way.
Created attachment 205804 [details] Patch Creator Ivan Motch <ivan.motsch@bsiag.com>
(In reply to comment #20) > I don't see the need to calculate the width of the rich text in a column. The > height is sufficient. I'm attaching a patch written by Ivan Motsch. This solves > the desired enhancement with an simple way. I disagree. To support API like TableColumn#pack(), we need to be able to measure the width. The height is determined by the Table anyway, since all rows always have the same height. Just to keep you posted, the markup-in-table feature is still under discussion in the RAP team. It still unclear how the text regions will be transmitted to the client (protocol) and how we can maintain compatibility with desktop applications. BTW, while patches are always welcome, it's currently an unfortunate point in time to create such extensive patches, since the protocol (bug 311355) will change the LCAs vastly. Currently, the problem is more in the area of integration, not implementation, anyway.
(In reply to comment #22) > BTW, while patches are always welcome, it's currently an unfortunate point in > time to create such extensive patches, since the protocol (bug 311355) will > change the LCAs vastly. Currently, the problem is more in the area of > integration, not implementation, anyway. I know this problem exactly because we need those patches for scout-rap. So once a week I get the current head from cvs and reapply every patch (and update them to the cvs head state). Thats a lot of work... The more I hope our patches will go into cvs head sooner than later (if they are ok ;-) )
(In reply to comment #23) > Thats a lot of work... The more I hope our patches will go into cvs head sooner > than later (if they are ok ;-) ) As I said, we're not sure whether sending markup directly to the client is a good idea. Not all clients have the ability to display markup, so some native clients would have to parse the html snippets. An alternative would be to encode regions with style attributes in the JSON protocol. Apart from this, code without junit tests doesn't have a chance to be committed to our CVS, sorry ;-)
A new implementation of markup in text for Table/Tree is in CVS HEAD. To enable it, you have to pass the constant RWT.MARKUP_ENABLED to the control setData with a value of Boolean.TRUE. You have to do it immediately after the control is created. Once, the markup in text is enabled it's not possible to disable it. Currently supported HTML tags are: b, i, br, sub, sup, big, small, del, ins, em, strong, dfn, code, samp, kbd, var, cite, q, abbr, span, img, a. "style" attribute is supported for all of them.
