Topic on Extension talk:DataTable2

Jump to navigation Jump to search

Column ordering bug and two feature requests

Cruickshanks (talkcontribs)

The DataTable2 Extension is a brilliant concept and work RV1971. Your extension has been extremely helpful to me.

Column Ordering - Bug

I have discovered a bug in the data entry <datatable2> tag. After saving the page, the tag shows the content of columns in alphabetical order rather than numerical order. For example, column contents are displayed after saving a page as Column1, Column10, Column11, Column12 ... Column19, Column2, Column20, Column21 ... etc. Thus, this bug only becomes apparent when creating tables with more than 9 columns.

For example, the following code would demonstrate this:

<datatable2 table="column order test" class="wikitable" columns = "column1|column2|column3|column4|column5|column6|column7|column8|column9|column10|column11|column12|column13|column14|column15|column16|column17|column18|column19|column20|column21|column22">
! column1
! column2
! column3
! column4
! column5
! column6
! column7
! column8
! column9
! column10
! column11
! column12
! column13
! column14
! column15
! column16
! column17
! column18
! column19
! column20
! column21
! column22

Fortunately, the <dt2-showtable> tag correctly displays columns as Column1, Column2 ... Column10, Column11, Column12 ... Column19, Column20, Column21 ... etc.

Field Separator - Feature Request No. 1

I have found that the DataTable2 Extension is intolerant of '|' (pipes) field separators with whitespace on either side. I have created a table which has more than twenty columns. Each row of my input data can be quite long and screen wrapping can be an issue. Due to 'human factors', it would be easier for humans to read and prepare the input data if whitespace was permitted on at least one side of the pipes. The difficulty of not accepting whitespace with pipes is also visible with the list of columns in the code example above.

Additional SQL Statements - Feature Request No. 2

I would like to be able to use the following SQL Statements such as:

  • GROUP BY <- most important for me

I do not think the Extension permits the use of these statements (or at least I do not know how to). Could these be added too please (or explained in Help Page)?

Thanks, Cruickshanks (talk) 10:34, 22 September 2014 (UTC)

RV1971 (talkcontribs)

Pleased to know that my extension is useful to somebody.

  • The bug is fixed in version 1.0.2 which I have just published.
  • Re Feature Request No. 1, I'm not totally sure what your point is. If you'd like a <datatbase2> tag to ignore whitespace around pipes, you can instruct it to consider it part of the field separator by adding the following attribute: fs="/\s*\|\s*/"
  • Re Feature Request No. 2, one would be tempted to make a fully-functional sql database out of this extension, since it would be logical to request a JOIN feature as soon as the GROUP BY feature has been implemented. I see a number of open questions there:
    1. How to express all this in attributes to <dt2-showtable> in a way that remains understandable.
    2. How to implement all this in code that remains maintainable.
    3. How to ensure efficiency of such queries.
I'm unlikely to find solutions in the near future. As an alternative, I'd suggest to use the Lua interface, query all records you need, and do further transformations on Lua level. This is clearly not efficient for large amounts of data, but the extension is not suitable for large amounts of data anayway.
Cruickshanks (talkcontribs)

Thanks RV1971,

  • I have installed version 1.0.2 and fields and columns all correlate. Thanks for fixing.
  • Re Feature Request No. 1, I added the attribute: fs="/\s*\|\s*/" which did the trick. Earlier, I had simplistically tried things like " | " and "| " without success. Thanks for the help.
  • Re Feature Request No. 2, I understand the points you make. I discovered that the extension Extension:External_Data#.23get_db_data_-_retrieve_data_from_a_database works very well with the DataTable2 Extension and seems to provide the extra functionality I sought. Indeed, the other extension seems to have greater functionality than the author intended - see Extension_talk:External_Data#This_could_be_a_bug.
    • An additional trick I discovered by accident, is that Extension:DataTransclusion and Extension:External Data provide an easy way to look beyond/across the logical tables. This means that a large logical table can be created over several pages/templates provided that the same table structure is used with discipline. For example, using DataTable2 Extension separate templates could be set up for the members of football teams. Then using Extension:DataTransclusion and Extension:External Data, and the database column names like dtd_04, the entire list of players for the entire football league can be extracted.
    • This then means that the author has two choices: can either create and manage one table for the whole football league, or create and manage smaller tables for each football team. This could offer much utility for various Wikiprojects!
    • (I have used and like the impressive Semantic bundle too, but recognise that your extension does offer an alternative approach that suits my needs better.)

I regret not letting you know in my first post of another minor bug. It is a bug that is easily worked around. After first installing the extension and creating a page with the <datatable2> tag, the following error message was generated by both versions 1.0.1 and 1.0.2:

Warning: Cannot modify header information - headers already sent by (output started at /home/mysite/public_html/mw/extensions/DataTable2/DataTable2.php:277) in /home/mysite/public_html/mw/includes/WebResponse.php on line 37

As there are only 275 lines of code in DataTable2.php, deleting the two 'blank' lines (276 and 277) at the end of the file fixes the error. It seems that there is some form of invisible byte order mark on one or both of those lines that is causing the upset.

Regards, Cruickshanks (talk) 10:18, 26 September 2014 (UTC)

RV1971 (talkcontribs)

Thanks for spotting the bug re blank lines. Fixed in version 1.0.3.

Reply to "Column ordering bug and two feature requests"