See
TWiki:Codev/AddTHeadAndTFootToTWikiTables
--
TWiki:Main/SvenDowideit - 08 Mar 2007
initial version commited. It would help considerably if twikitable processing was not quite so line by line.
--
SvenDowideit - 26 Mar 2007
The unit tests fail because the "actual" URL for sorting in table headers contains something like
/../bin/TestRunner.pl
. The construction of "expected" URLs for sorting columns has nothing between the host and the path, so this needs to be enforced for the URL construction in
TWiki::Plugins::TablePlugin::Core
, too. The easiest way is to define
$ENV{SCRIPT_NAME}
in the test cases'
set_up
routine (which I'm going to commit).
--
TWiki:Main.HaraldJoerg - 03 Apr 2007
Done (r13249) --
TWiki:Main.HaraldJoerg - 03 Apr 2007
I have this feeling that you did a different fix to what i was looking at
i was looking at this this morning, and noticed that the test succeeds if you run the
TableRendeing.pm test by itself, but if you run
TWikiSuite.pm it fails.
ie, there is probably a big issue wrt sessions persisting after teardown.
--
TWiki:Main.SvenDowideit - 03 Apr 2007
Nope, that has nothing to do with session teardown. In my install the test fails for plain
TableRenderingTests.pm
as well, though with a different "actual" value. When running from the command line, many of the variables in
%ENV
on which
CGI.pm
relies are not initialized, so results are more or less random depending on the value of variables in the caller's environment. Either the test cases must mimick a CGI environment, or the code needs to take care for special cases when called from the command line.
--
TWiki:Main.HaraldJoerg - 03 Apr 2007
fixed it properly - if you want to match a variable, why not use that variable...
one fewer failing unit test
--
SvenDowideit - 24 Apr 2007
Was waiting for release.
I'm re-opening this, for the reasons given in
TWiki:Codev/AddTHeadAndTFootToTWikiTables. The current scheme makes life too difficult for any JS component that expects a reasonable construction for tables.
CC
This change has
- Broken the EditTablePlugin totally.
- Broken many unit test cases
- Still half implemented and abandoned for more than a month.
If noone is going to finish this then please remove the changes already made so we can get back to working code. The bugs introduced by this prevents finishing the testing and fixing of other changes made in
EditTablePlugin.
--
TWiki:Main.KennethLavrsen - 27 May 2007
I have modified the code as described above. All relevant testcases pass.
I have no idea what "Broken the
EditTablePlugin totally" means, so I can't test that case, though it appears to work correctly for me.
CC
"Broken the
EditTablePlugin totally" is a 99 % accurate description.
You need the last 1%.
Make sure the table you test with has a header and several rows and columns.
Like this one
NOW EDIT! And LOOK!
And if you cannot see the "totally broken" - then you need glasses.
I have spent hours on this problem and have confirmed that it was this new feature that broke the plugin. And your latest changes did not fix the problem. Testing to me means trying to both view and edit a table and not just a table with one row and one cell but a complex one with several of the features combined. Unit tests do not reveal this kind of errors.
See also Item4029 which is the actual error covering this bug. But you cannot claim this bug item ready for release when it has created Item4029. There is for sure some part of this that needs to get recoded - and
tested
--
TWiki:Main.KennethLavrsen - 28 May 2007
Let's get practical here; THEAD and TFOOT are standard HTML. They are required for a lot of the more advanced javascript features, such as those in the google and yahoo UIs. We can disable heads and foots, but only at the cost of compatibility with those UIs. On the flip side we have the
EditTablePlugin, and a new and relatively untried feature for moving rows around, that barfs at THEAD and TFOOT (standard table construction). The functionality of this feature is also available from the
EditRowPlugin, which
does handle thead and tfoot correctly, so it's perfectly reasonable to expect the
EditTablePlugin javascript to function correctly with standard HTML tables.
On balance I believe that the core change is correct, and that the plugin needs to be fixed to correctly handle standard HTML tables. Hence this bug is "waiting for release" and
Item4029 is open and urgent.
CC
I reopen this because there are test cases that fails because of this.
The following tests are broken in the TestCases web. At least these 3 are not updated.
--
KennethLavrsen - 28 May 2007
Lets get practical: Any feature that breaks another feature is incomplete. If this bug cannot be solved for the TWiki 4.2 release we ned to revert
Item4029.
This is an example of not using our resources carefully enough, we are stretched too thin. We have now two complex plugins that do almost exacly the same, but not quite the same:
EditRowPlugin and
EditTablePlugin. I strongly suggest to drop one. Crawford does not seem to like the codebase of
EditTablePlugin (which is fine), so once
EditRowPlugin covers 100% of the
EditTablePlugin feature set we can replace the codebase of
EditTablePlugin with the one of the
EditRowPlugin.
--
TWiki:Main.PeterThoeny - 04 Jun 2007
I have said it several times in the last 2 weeks
the current unit test failures have absolutily NOTHING to do with this change.
if you bother to read the errors, you will see that someone (Arthur tells me it was Micha) made changes to the css output of the table system.
Peter is right, jumping up and down with out even analysing to make sure you are right, and then ignoring every time someone tells you are wrong, is a waste of resources.
--
TWiki:Main.SvenDowideit - 06 Jun 2007
closing - open a new bug if you find anything new
--
SvenDowideit - 19 Jul 2007