Categories | Question details Back To List | ||
Loading from HTML with colspan/rowspans 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: http://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, Answer posted by Support on Oct 20, 2008 04:02 Problem in parsing or source table, while improting initial data in grid. Answer posted by Yudhi Seymour on Oct 20, 2008 19:49 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 Answer posted by Support on Oct 21, 2008 01:58 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. |