Wrapping non-breakable content of Table widget

Andrzej Michalec

February 6, 2017 at 11:50 pm #3634

Dear SPARK team,

if Table component has cells with content that is not automatically wrapped (like tekst without breaking points like whitespaces) then table does not respect viewport size and renders content outside of window. Note that horizontal scrollbar does not appear, meaning rightmost columns are unreadable. See attached screen with upper table showing such problem and lower table with applied some local fixes.

It could be fixed purely with CSS by adding “table-layout:fixed; word-wrap:break-word” style to “table” tag of discussed coach view, however fixed table layout requires that firs row in HTML table has styles defining column widths. Currenlty Table SPARK component does not do it: its column specs are used to generate styles for TD tags, while first row of table is column header and THs are missing widths. Our workaround is to introspect table widget, read column specs and decorate THs with column widths same as TDs are marked now.

Please provide a receipt how to fix the issue without workarounds (CSS only) or plan for fix.

Steps to reproduce:

1. Create table with two columns: first 20% width and second with 80% width
2. Place Tekst Output components to both columns and bind it to correct input data
3. Make data of 2nd colum to be non-breakable like very long file path without white spaces
4. Observe table rendered outside of viewport

 

regards,
-andy.

SPARK Support

February 16, 2017 at 3:14 pm #3735

Hi Andy,

Thank you for providing this feedback with the CSS.  I have provided a similar work-around for certain customer applications.

This is considered to be more of a styling decision left up to the discretion of the developer.

Here is a SPARK BPM File List control with CSS added to specific columns for long file names: “max-width: 150px; word-wrap: break-word;”

Regards,

Stephen P.

Andrzej Michalec

February 21, 2017 at 1:45 am #3783

Hi Stephen,

thank you for suggestion, it works in most cases even though “max-width” is quite counter-intuitive in this context as it limits width when shrinking down the size (does not allow to make width less than “max-width”). Having multiple columns with relative widths (e.g. 20% and 80%) my approach allows to keep proportions no matter the size of viewport, while using “max-width” sets hard stop when downsizing width so that column cannot get smaller that specified value. Once again it would be nice if SPARK widget injects width to TH elements so that table-level word breaking would work seamlessly as well.

I accept your receipt even though coach technology gets more and more quirks and places to hack layout (positioning configuration, spark “appearance” settings, CSS styling on coachviews) that makes a lot of headache as DOM model is out of BPM developer control.

regards,
-andy.

 

SPARK Support

February 22, 2017 at 12:16 pm #3805

Hi Andy,

Please keep in mind that as an Enterprise customer, you do have the ability to submit tickets.  Enhancement Requests can be submitted with specific use case and requirements to be evaluated for potential inclusion in future releases.

Regards,

Stephen P.