Comments

willvincent’s picture

Here's a properly formed patch based on miqmago's malformed patch from http://drupal.org/node/806982#comment-6890454 (file paths are based on D8 directory structure in the patch).

willvincent’s picture

Status: Active » Needs review
marcingy’s picture

Status: Needs review » Closed (duplicate)

The d8 version needs to be committed first. Once that happens d7 patch needs to be attatched to that issue.

joseph.olstad’s picture

Issue summary: View changes
Status: Closed (duplicate) » Needs review

D8 patch was committed, Pol has an updated patch in that issue, copy that patch here as this is the new policy.

joseph.olstad’s picture

Issue tags: +Drupal 7.60 target
pol’s picture

StatusFileSize
new6.05 KB

Here's the patch.

Status: Needs review » Needs work

The last submitted patch, 6: 1892654.patch, failed testing. View results

pol’s picture

Status: Needs work » Needs review
StatusFileSize
new6.05 KB

Here's the updated patch.

pol’s picture

StatusFileSize
new6.08 KB

Here's a better patch with an improved coding style.

The last submitted patch, 8: 1892654.patch, failed testing. View results

pol’s picture

StatusFileSize
new7.07 KB

New patch, including tests.

pol’s picture

Issue tags: +Pending Drupal 7 commit
joseph.olstad’s picture

Status: Needs review » Reviewed & tested by the community

It's already in D8, passes tests, has test, looks good.
Although I've never actually had to use this yet, others are.

joseph.olstad’s picture

Issue tags: -Drupal 7.60 target +Drupal 7.70 target

Bumping to 7.70, this didn't make it into 7.60

apotek’s picture

Just re-rolling the excellent patch from @Pol at comment #11 to match current state of drupal 7 (7.63) as the old patch no longer applies.

Endless rework of good work while waiting for the merge to master.

Status: Reviewed & tested by the community » Needs work
pol’s picture

Status: Needs work » Reviewed & tested by the community

The patch still apply on my side, without any troubles.

pol’s picture

Updating credits.

pol’s picture

pol’s picture

Issue tags: +Already In D8
pol’s picture

Issue tags: -Drupal 7.64 target +Drupal 7.65 target
fabianx’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/docroot/includes/theme.inc
@@ -2069,55 +2084,66 @@ function theme_table($variables) {
+  // Rows and footer have the same structure.
+  $sections = array(
+    'rows' => 'tbody',
+    'footer' => 'tfoot',
+  );
+  $variables['rows'] = $rows;
+  foreach ($sections as $section => $tag) {
+    if (!empty($variables[$section])) {

I'd like a little restructuring here:

$sections = [];
$sections['tbody'] = $rows;
if (!empty($variables['footer']) {
  $sections['tfooter'] = $variables['footer'];
}

That will simplify the code and make it easier to ready.

---

I delayed committing that as the changes looked massive, but it was overall just structure changes, which is okay this time, but next time let's please do cleanup separate from feature development as it makes things harder to review than necessary.

pol’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: -Drupal 7.65 target +Drupal 7.67 target

Hi Fabian,

Thanks for replying.

We cannot do the change you requested.

The $sections variable is a mapping of keys from $variables array into their respective HTML tags and they are processed using the same mechanism, this is why this is abstracted into this variable, to avoid code duplication.

rows => <tbody>
footer => <tfoot>

If we implement your logic, we won't be able to map the $rows to <tbody> tag and $footer to <tfoot> tag.

pol’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new6.57 KB
new3.36 KB

After a discussion in IRC, I got the Fabian's point.

Here's an updated patch and the interdiff.

fabianx’s picture

Status: Needs review » Needs work
  1. +++ b/includes/theme.inc
    @@ -2069,42 +2086,54 @@ function theme_table($variables) {
    +  $sections = array(
    +    'tbody' => $rows,
    +  );
    

    My bad - we need to check for !empty() like before to populate 'rows' in sections.

  2. +++ b/includes/theme.inc
    @@ -2069,42 +2086,54 @@ function theme_table($variables) {
    -      else {
    -        $cells = $row;
    -        $attributes = array();
    -        $no_striping = FALSE;
    ...
    +      if (!$no_striping) {
    +        $class = $flip[$class];
    +        $attributes['class'][] = $class;
           }
    -      if (!empty($cells)) {
    -        // Add odd/even class
    -        if (!$no_striping) {
    -          $class = $flip[$class];
    -          $attributes['class'][] = $class;
    -        }
     
    -        // Build row
    +      // Build row.
    +      if (!empty($cells)) {
    

    Is there a reason for moving the no_striping out of the `!empty($cells)`?

    Looks wrong - or rather needs a justification before that can go in.

The nice thing about this new approach is that the indentation almost remains the same, which makes this much simpler to review than before :D.

pol’s picture

Status: Needs work » Needs review
StatusFileSize
new6.51 KB
new3.3 KB

Updated patch.

I moved back the no_stripping logic into the condition as it was before.

pol’s picture

Updating credits - adding Fabian.

fabianx’s picture

Status: Needs review » Needs work
  1. +++ b/includes/theme.inc
    @@ -2069,42 +2086,56 @@ function theme_table($variables) {
    +  if (!empty($variables['rows'])) {
    +    $sections['tbody'] = $variables['rows'];
    +  }
    

    Should be !empty($rows) as that is the weird header / rows structure.

  2. +++ b/includes/theme.inc
    @@ -2069,42 +2086,56 @@ function theme_table($variables) {
    +      $cells = $row;
    +      $attributes = array();
    +      $no_striping = $tag === 'tfoot';
    +
    ...
    -      else {
    -        $cells = $row;
    -        $attributes = array();
    -        $no_striping = FALSE;
    -      }
    

    This change is problematic because it changes the current behaviour.

    What would work for me is to keep the code as-is, but initialize the $no_stripiing once before the for loop if the tag is tfoot.

    That would change the default just once.

  3. +++ b/includes/theme.inc
    @@ -2069,42 +2086,56 @@ function theme_table($variables) {
    +      // Build row.
    ...
    -        // Build row
    

    This move is unnecessary.

pol’s picture

Status: Needs work » Needs review
StatusFileSize
new6.55 KB
new1.56 KB

Thanks, updating the patch, interdiff provided.

fabianx’s picture

Status: Needs review » Needs work
+++ b/includes/theme.inc
@@ -2069,42 +2088,56 @@ function theme_table($variables) {
+    $no_striping = $tag === 'tfoot';
+
+    foreach ($content as $number => $row) {
+      $cells = $row;
+      $attributes = array();
+
+      // Check if we're dealing with a simple or complex row.
...
-      else {
-        $cells = $row;
-        $attributes = array();
-        $no_striping = FALSE;
-      }
+

Let's not remove the else - the additional line is fine though.

pol’s picture

Status: Needs work » Needs review
StatusFileSize
new6.43 KB
new797 bytes

Updating patch.

fabianx’s picture

Status: Needs review » Needs work
  1. +++ b/includes/theme.inc
    @@ -1948,6 +1948,8 @@ function theme_breadcrumb($variables) {
    + *   - footer: An array of table rows which will be printed within a <tfoot>
    + *     tag, in the same format as the rows element (see above).
    

    I think it might be good to say that no_striping defaults to FALSE for 'rows' and TRUE for 'footer'.

  2. +++ b/includes/theme.inc
    @@ -2069,23 +2088,38 @@ function theme_table($variables) {
    +    $no_striping = $tag === 'tfoot';
    +
    
    @@ -2097,14 +2131,15 @@ function theme_table($variables) {
             $no_striping = FALSE;
           }
    

    Let's do this differently and put:

    $default_no_striping = ($tag === 'tfoot');

    Then use $default_no_striping both in the ternary operator as well as in the else block.

pol’s picture

Status: Needs work » Needs review
StatusFileSize
new6.71 KB
new1.68 KB
fabianx’s picture

just nits remaining!

Looks very great already :).

  1. +++ b/includes/theme.inc
    @@ -1948,6 +1948,11 @@ function theme_breadcrumb($variables) {
    + *     that the no_stripping boolean has no effect, there is no rows stripping
    

    s/stripping/striping/

  2. +++ b/includes/theme.inc
    @@ -2049,17 +2057,31 @@ function theme_table($variables) {
    -  // Format the table header:
    +  // Assigning back the $rows variable into $variables as we won't modify it
    +  // anymore.
    +  $variables['rows'] = $rows;
    

    This is no longer needed as it's unused.

  3. +++ b/includes/theme.inc
    @@ -2069,23 +2091,38 @@ function theme_table($variables) {
     
    -  // Format the table rows:
    ...
    +
    

    I think we can change that to '// Format the table rows and footer'

pol’s picture

StatusFileSize
new6.77 KB
new1.2 KB

Forget this one, I forgot to fix a typo.

pol’s picture

StatusFileSize
new6.77 KB
new1.2 KB

The last submitted patch, 35: 1892654.patch, failed testing. View results

fabianx’s picture

Status: Needs review » Reviewed & tested by the community

RTBC - let's get that in

  • Fabianx committed 85be7c5 on 7.x authored by Pol
    Issue #1892654 by Pol, willvincent, Fabianx: D7 Backport: theme_table()...
pol’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Pending Drupal 7 commit

Thanks all!

joseph.olstad’s picture

Nice work! Thanks!

Merci Pol
Dankeschön FabianX

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.