Re: [ic] table-organise question/gripe

[Peter <suppressed>]

On 10/24/2005 09:39 PM, Mike Heins wrote:
> "Messed up" is really not enough of a problem description for me to call
> something a bug, and I would argue the first was not necessarily a bug
> at all as we have not considered all the ramifications of why the table
> parameter was implied. Even if there is not a reason, it would seem to
> be better called a deficiency.
>
> Have you considered ramifications of your second "bug fix"? And what
> is the problem with not supplying the empty table cell on the end
> of the row?
>
>
> > Here's a diff that includes both referenced bug fixes (probably suffers 
> > from word-wrap so best to implement manually)...
>
>
> I guess you are using [table-organize] only for columnization? There
> doesn't seem to be a reason to use it otherwise if you know the exact
> size....

Ok, I'll back up a bit and explain what I'm using it for and how it 
looks without the fix...

I'm trying to display featured products on the front page of the site as 
follows:

Description 1     Description 2     Description 3
Price 1           Price 2           Price 3
Thumbnail 1       Thumbnail 2       Thumbnail 3


Description 4     Description 5     Description 6
Price 4           Price 5           Price 6
Thumbnail 4       Thumbnail 5       Thumbnail 6

...etc...

Descriptions vary in length, sometimes wrapping to 2 or 3 lines.  Prices 
for items which are on sale show both the regular price and the sale 
price, taking up two lines whereas non sale items only take up one line 
for the price.  So the traditional method of organising the data by 
putting each item into it's own table makes it very difficult to keep 
tings lined up properly and it ends up with the thumbnails all over the 
place.

To get the browser to line it all up nicely I want to have one large 
table (without smaller tables inside of it) and have each description in 
a seperate cell, each price in a seperate cell, each thumb in a seperate 
cell, etc.  table-organise can do this nicely by using both the rows and 
columnize attributes to table-organize i should be able to feed the data 
to it in order of all the data for item 1, then all the data for item 2, 
etc, and it will spit out the data in the order i need it for the 
browser to display it in the table properly.  In order to do this I need 
table-organise to not try to break up every 3 or four rows into seperate 
table by the insertion of </table> and <table>, hence the need to be 
able to not have the table attribute implied or a way to explicitly turn 
it off.

Ok now for the second problem where it appears "messed up".  What 
happens is if we take the above example but with four items instead of 6 
(so that the last row of items is not full) then it ends up looking 
something like this...

Description 1     Description 2     Description 3
Price 1           Price 2           Price 3
Thumbnail 1       Thumbnail 2       Thumbnail 3


Description 4     Price 4           Thumbnail 4

which is obviously not what we want.  By padding out the right two 
cell-blocks before re-arranging everything for columnize we end up with 
it looking like this...

Description 1     Description 2     Description 3
Price 1           Price 2           Price 3
Thumbnail 1       Thumbnail 2       Thumbnail 3


Description 4
Price 4
Thumbnail 4

...which is exactly how it should look.

I don't think it could ever have properly padded out anything that uses 
rows and columnize together before.  It probably would cause the use of 
table-organise with columnize but without rows to display any remaining 
blank space on the right side instead of on the bottom.  it shouldn't 
have any effect if neither rows or columnize isn't used and if rows is 
used without columnize it will add more padding than before but likely 
have no visible effect.

Considering all of this maybe the following would be better...

        while(@cells) {
                if ($opt->{columnize}) {
                        while ($rows && scalar(@cells) % ($rows*$cols)) {
                                push @cells, "<td>$opt->{filler}</td>";
                        }

                        my $cell_count = scalar @cells;
                        my $row_count_ceil = POSIX::ceil($cell_count / 
$cols);
                        my $row_count_floor = int($cell_count / $cols);
                        my $remainder = $cell_count % $cols;
                        my @tmp = splice(@cells, 0);
                        my $index;
                        for (my $r = 0; $r < $row_count_ceil; $r++) {
                                for (my $c = 0; $c < $cols; $c++) {
                                        if ($c >= $remainder + 1) {
                                                $index = $r + 
$row_count_floor * $c + $remainder;
                                        }
                                        else {
                                                $index = $r + 
$row_count_ceil * $c;
                                        }
                                        push @cells, $tmp[$index];
                                        last if $r + 1 == 
$row_count_ceil and $c + 1 == $remainder;
                                }
                        }
                }

                while (scalar(@cells) % $cols) {
                        push @cells, "<td>$opt->{filler}</td>";
                }


Note that the first instance of padding would only take effect if both 
columnize and rows are used.  The second instance would not take effect 
if the first instance did because @cells would already be padded out and 
would return a modulus of 0.  Then every instance of padding would be 
the same as before except where both rows and columnize are used.

Peter
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users