TinyMCE editor seems to lack the capability of applying table cell properties to the whole table column (which would be much less trivial problem, than applying to the whole row - that functionality is there).
Is there a working soultion for that (patch, plugin..)?
Related
I'm using Postgres to store formulae and elements of formulae across two tables. Basically, you have something like:
Elements Table
symbol
content
pi
3.1.45
lune
42
Formula Table
symbol
content
area
pi*r^2
rugsize
area*lune
So, formulae can use elements but also other formulae in their content field. For this reason (and for general reduction of confusion) I would like to make symbol unique across both tables.
I can, of course, in the code that's doing the insertion, look up the entries before adding them and refuse to add a duplicate symbol. (I probably will do this, but I don't want the database reliant on that.) I could also require a tag within the formula table to specify when it's using another formula:
symbol
content
rugsize
f(area)*lune
I'm not crazy about that since it puts a burden on the user to remember that, or on the coder to secretly add and remove the "f()".
Everything I found on Stack and elsewhere went the other way: Forcing a column value to be present in another table, except for one suggestion that the unique items be kept in a separate table.
symbol
area
lune
pi
rugsize
And then...actually, I'm still not sure how that would work at the DB level.
So, is there a way to do this with constraints or foreign keys, or must I write a trigger for each table to look into the other table?
Addition: I've simplified here greatly but the elements table is much more complex than I'm showing and has little in common with the formulae table.
Edited to add the above addition and to try to fix the one-column "symbol" table which looks fine in the editing preview but does not format correctly on the actual page.
Is it possible to merge duplicates in a sapui5 smart table?
In a smarttable (with a responsive table) we are grouping values by supplier and would like to merge duplicated values into one cell to get a better readability of the responsive table.
Outside of Fiori elements (smarttable) this can be done in the column definition in XML using mergeDuplicates: true.
Should be possible to merge duplicates via SAP UI5 Visual Editor, the properties of controls are available there.
Not all properties are subject to change. Only properties that have been enabled for editing may be changed.
Best,
Shanir
My e2e-test for ui-grid is the following:
I'm adding the new item with the name that includes timestamp, saving it to the server.
I'm checking if the item with this name has been added to the ui-grid table.
The problem is that the table can get very big and ui-grid apparently uses lazy loading and puts only the visible rows to the DOM. I found this library of helper methods for testing, but it doesn't provide anything to search for the rows which are not in visible now.
So, question, is one of the following is possible in my Protractor test?
1) can I check how many rows do I have in my ui-grid table?
2) can I search for the certain cell by text, even if the cell is not visible?
1) Can I check how many rows do I have in my ui-grid table?
As long as the row is in the DOM, you can access it. However, if it's not visible you won't be able to do any operation on it (e.g. click). To get number of table rows you can use count:
$$('table tr').count();
2) Can I search for the certain cell by text, even if the cell is not visible?
Yes, you can search for (but not interact with) the cell as long as it's in the DOM. It doesn't have to be visible. But selecting elements by their text is rather fragile, so you should try to use some other method, if possible.
I have a 2-column SWT Table that uses TableViewer. Trouble is that I can only select (and edit) cells in the first column -- clicking on the second column does nothing.
I read from somewhere (lost the link) that there's no easy way to get such functionality (!) -- you're supposed to mess around with several extra concepts if you want to select (and edit) different columns in your table.
This snippet
(http://www.goneeded.com/snippet/eclipse/JFace/Viewers/Snippet035TableCursorCellHighlighter.html)
seems to be relevant, but it's not clear which part of it is necessary and it has depenendencies to other snippets. I tried to get it working but it did nothing.
Seems that new table editing and cell-selecting features were added in Eclipse 3.3 -- is there a tutorial or smth available on how to use them? The snippets are too cryptic for me.
You should be able to edit and select cells independently. You might have the SWT.FULL_SELECTION style bit set on the Table constructor. That forces every selection to span the whole row instead of a single cell.
I'd check out this tutorial for more on TableViewers:
http://www.eclipse.org/articles/Article-Table-viewer/table_viewer.html
I am writing code that generates both PDF and RTF documents, depending on the user's selection. The information in both documents is the same.
Until now, we were using classes like Table, Cell, HeaderFooter, etc., which are rendered into the correct form by the documentwriter (either PdfWriter or RtfWriter2).
However, the further I get into trying to make changes (mostly because the upgrade to iText 2.1 left the spacing a little quirky), the more I'm being told to "use PdfpTable", or "Use pageEvents to set headers". It seems like a lot of the generic classes are being deprecated.
I am thinking of revamping the code to separate out the table creations for PDF and RTF. However, all the iText tutorial stuff seems to actually recommend using Table in an instance where both PDF and RTF documents are needed.
Additionally, it appears that while there is a PdfpTable class, there is nothing similar for RTF, so I would be using Table anyway, which would leave me vulnerable to all the quirks that come along with the now unsupported Table class.
Basically, what are the benefits/downsides of separating the code into two sections -- one to create PDF documents, and one to create the same documents in an RTF format, if that was selected? And where does SimpleTable come in to all of this? Will it give me the flexibility that I need?
Thanks!
From the book iText In Action, end of chapter 6:
If you look at the iText API, you’ll also find some other table classes. com.lowagie.text.Table is the original table class; it dates from the early iText days. It uses class com.lowagie.text.pdf.PdfTable internally to render a table to PDF (don’t confuse this class with PdfPTable).
There’s also the newer SimpleTable class, which tries to form a link between
PdfPTable and Table. It’s able to translate itself to a PdfPTable if you add it to a
document that writes PDF or to a Table if you’re producing HTML or RTF. [...]
The major disadvantage of the Table class is that it’s no longer supported. Different
people have fixed most of the known issues, but today not a single person
understands if and how all the Table-methods work. If you decide to use this class,
you’re more or less on your own, and you’ll encounter lots of quirky layout issues
based on historical design decisions. However, this doesn’t mean you can’t make
good use of the Table class.
Advantages of the Table class
With the Table class, you can generate a table structure that can be rendered in
PDF, RTF, and HTML. If you compare the results, you’ll see there are small differences
in the way the table is rendered. This is normal; not every table feature is
supported in every document format.
You can generate a table in PDF, HTML, or RTF using the same code.
You can set padding and spacing the way it’s done in HTML.
You can use the row span without having to resort to nested table.
You can change the number of columns even after you’ve added cells.
You can add cells at specific positions (the number of rows is augmented
dynamically).
You can delete a column before adding the table to the document.
You can let iText add the Table as if it was a PdfPTable.
You get a PdfPTable object based on the Table object.
As opposed to PdfPTable, you can add cells to a Table in a random order, and add
or delete columns if needed. You can even translate a Table to a PdfPTable if you
didn’t use setRowspan().
There’s also the SimpleTable, class, which is a simplified version of (PdfP)-Table. When adding a SimpleTable to a PDF document, iText first attempts to add
the table as a PdfPTable; if this fails, it’s added as a Table. When adding a SimpleTable to an RTF or HTML document, it’s added as a Table. SimpleTable differs
from the Table and PdfPTable in the sense that it reintroduces the concept of rows.
This can be handy if you’re parsing an XML file that has a table-row-cell structure.
If the tag corresponding with the rows has attributes, you don’t have to define this
property for each cell in the row separately; you can set the property for the entire
row at once.
Summary
PdfPTable should be your first choice; but depending on the requirements defined for your project, there can be good reasons to opt for Table or SimpleTable.