[ic] table-organise question/gripe
Peter
peter at pajamian.dhs.org
Tue Oct 25 01:51:00 EDT 2005
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
More information about the interchange-users
mailing list