Listing module (Auflistung) corrections and enhancements

[ghost]

mod_listing.php (#6337)

• correctly handle expressions in the column list of both list and info (virtual columns)
  e.g. concat(lastname,', ',firstname) as "Name".
  Fix wrong headings in such case.
• support virtual columns in the user query (can search on Name, e.g.)
• fix wrong query if WHERE clause (list and info) contains OR
• support insert tags also in the detail WHERE clause
• add class numeric to numeric list cell (allowing right-alignment)
• suppress link to detail record if that would not be displayed due to the detail WHERE clause (Modultype Auflistung Detailseitenbedingung - Details-Link verstecken #6332)

templates

• suppress link to detail record if that would not be displayed due to the detail WHERE clause (Modultype Auflistung Detailseitenbedingung - Details-Link verstecken #6332)

dca/tl_module.php

• fix parentheses of info expression stored as HTML entities (Listing module (Auflistung) causes SQL error with expression in list_info column #6338)

[leofeyer]

I have fixed the bugs you mentioned in 590cde7. Not sure about the features though, especially your implementation of virtual fields.

[leofeyer]

BTW, here's a regex that allows for CONCAT(firstname,' ',lastname) AS name:

// line 113
$arrSearchFields = preg_split('/,(?=(?:[^\(\)]*\([^\(\)]*\))*[^\(\)]*$)/', $this->list_search);

// line 252
$arrFields = preg_split('/,(?=(?:[^\(\)]*\([^\(\)]*\))*[^\(\)]*$)/', $this->list_fields);

This might be a first step towards virtual fields.

[ghost]

I'm sorry I was too busy with other projects so that this answer is rather late... I have checked my changes again and admit they could be explained a bit more.

With virtual column I just meant the result column produced by an expression - I should use another term like "expression column", as "virtual columns" are table features in Oracle, SQL Server and even MariaDB. An expression may be something like CONCAT(firstname, ' ', lastname) as "Name" but can be much more complex, e.g. a subquery. While supporting this significantly extends the usefulness of ModListing, there are a few challenges:

• Column header labels: simply splitting the column list fails with expressions, so will your regexp (and any other) on sufficiently complex expressions. Here SQL is your friend, it provides them in the result set. Therefore I moved the THEAD processing after the TBODY processing, and in TBODY code I collect the resulting column names for the header list. No more need to parse list_fields just to get the headers.
• When I allow search on an expression-generated column, I cannot simply add it to the where clause - the column does not exist yet on that level. I need something like select * from (select ...) where mycolumn = .... This is the reason for restructuring the SQL build and for $strOuterWhere etc. Detecting if the search is for an expression is a hack.
• But with this subquery format, MySQL barks if the PK column occurs twice, one added automatically, one contained in list_fields - only in a top-level select this is tolerated (strange enough).

Currently, I test my version merged with 3.2.9/3.3.RC2, improving some parts. After that and 3.3 release), have to find out how to update the pull-request.

Additionally, an extended version is in the works, which in addition supports a fully-blown SQL query. Not for the core, I guess.