Hi,
We are currently in the process of attempting to convert reports in HTML format to use the dhtmlxgrid.
Our current reports make extensive use of column and row span and we would like to add the fixed header and frozen column functionality which you provide.
In terms of development time, it would be most efficient for us to make use of the ability to load a grid from an existing HTML table.
I read the following KB article:
dhtmlx.com/docs/products/kb/index.shtml?q=5290
You say that “not all XML attributes can be mapped to HTML ( for example rowspans will not work while loading from HTML )”.
Is there any reason why this is so? It seems to me an irrational limitation, given that rowspan and colspan are features of HTML tables and not XML.
Any insight or advice that you could share would be appreciated!
Cheers,
Problem in parsing or source table, while improting initial data in grid.
If rowspan attribute was just defined and not affect source table - it would be not a problem, but rowspan attribute enables native table row-span which, makes table parsing impossible. ( code will need to
Technically it possible to use attribute with some different name and slightly change code in dhtmlxgrid_start.js to map such custom attributes to “rowspan” in-grid attributes. In such case it would be possible to define both col and row spans in HTML.
Thanks for the response.
Is it fair to say that the difficulty in parsing is due to the fact that cells defined in a previous row (using rowspan) are omitted in HTML, whereas in your XML format they need to be defined in each row? If so, I can see how that would present a challenge, but surely it should still be possible to parse the table by handling that case.
Regardless, I’ve got the XML format working, so this is not a drama for me, but it’d be nice to for the HTML load to have all of the functionality of the XML load.
Cheers
The grid has unified parsing approach, which based on case when each row is separate entity, not related to other rows. Such approach allow to organize single core , which can work in any mode ( plain, treegrid, paging, smart rendering ) with any kind of incoming data. It works for HTML table as well, but in case of rowspans, we can’t just take the info from related table row, we need to analize all table, to be sure that some cell of row is not skiped because of rowspans.
>>but surely it should still be possible to parse the table by handling that case.
yep, it possible, but as result final routine will need a separate rendering approach ( which will drop ability to use paging|smart rendering ) or will result in performance problem for big tables ( because we will need to analize a lot of data for each row )
We will recheck possibility of such feature, but I’m not sure that it will be added in nearest time.