Item5217: EditTablePlugin does unwanted merging of cells because it no longer leaves space in empty cell

Latest EditTablePlugin now removes the vital spaces that must be kept in empty table cells to prevent cells from merging.

All our weekly reports are goofed up now.

example

-- TWiki:Main/KennethLavrsen - 07 Jan 2008

I see in this example the cells are merged already.

-- TWiki:Main.ArthurClemens - 07 Jan 2008

This is cause by a change that prevented merged cells from getting expanded: Item4910, solved in the batch of Item3890.

-- TWiki:Main.ArthurClemens - 07 Jan 2008

No the cells in the example got merged by editing and saving and editing and saving the table in EditTable. It started with a non merged table

-- TWiki:Main.KennethLavrsen - 07 Jan 2008

I have found a fix. Too eager trimming was going on.

New test - the bottom right cell should not get voided.

-- TWiki:Main.ArthurClemens - 08 Jan 2008

No the fix is not correct.

When you save an empty cell it leaves behind no white space.

Example below is a table with 4 columns. You only see 3 because some cells are merged.

When you edit this and save again the EditTablePlugin has always added ONE space between the bars

If it does not it means that each time a user deletes all the text in a cell it merged with the cell to the left. This is not what the user expects. If he deletes all content and saves he expect an empty cell and not a merged cell. You have to change the EditTablePlugin back so it always fills one space between two bars if there is no characters between.

-- TWiki:Main.KennethLavrsen - 08 Jan 200

Perhaps you tested when SVN was not updated yet? Because I see the correct behavior:

1. A cell with a space is given a space in edit mode
2. When the user deletes this space the cells are merged
3. When the user re-adds a space the merged cells are split

-- TWiki:Main.ArthurClemens - 08 Jan 2008

Yes I have SVN updated. And you have the behavior wrong.

As I wrote above. When the user deletes the space in EditTablePlugin edit mode the cells should not merge. The plugin should add the missing space to avoid the merge. When the user deletes the content of the cell he wants to see an empty cell, not a merged cell. Normal users will not see the logic in having cells merged because he empties the cell. You cannot expect normal users to add a space. That would be totally geeky. The EditTablePlugin has added this space since the beginning. You cannot change this behavior.

Just look at the very first example I made which is from an actual application we use everywhere. The minute people move a date from the Forecast column to the Actual column meaning that the milestone has been reached they will leave behind an empty cell in the Forecast column. They will not understand that they have to leave an space character which you cannot even see. And when they save the result is that the Planned and Forecast cell merges and the result is goofy. It does not work. I had to revert the TablePlugin back to a December 17 version because my users were complaining that the weekly report app was broken so I know this confuses the users.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

The EditTablePlugin has added this space since the beginning. You cannot change this behavior. - yes we can. Because it conflicts with Item4910. It should not add a space when it is not there.

They will not understand that they have to leave an space character which you cannot even see. - they don't need to change anything, just leave the space where it is.

-- TWiki:Main.ArthurClemens - 08 Jan 2008

No when they delete all the content of a cell - and they do all the time - I know - I see it happening daily when milestones go from Forecast to Actual. They delete the cell and add a date in the Actual. And then they get the unwanted merge.

You have changed the way this plugin has behaved since its birth.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

Just checked our material planning app. It also gets goofed up completely the minute someone empties the content of a cell. It won't work like this Arthur.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

Do you propose to throw away the fix for unwantedly unsplitting merged cells? This way you cannot have merged cells in an edit table.

-- TWiki:Main.ArthurClemens - 08 Jan 2008

Yes. That "feature" creates more trouble than it solves.

The users will never understand that clearing field in a table causes a merge.

If we want a merge feature in EditTable is may be better to make an extension to the EDITCELL tag so that when you edit you see the merged cell. But then please do that AFTER 4.2.0. Right now we need the EditTable to work like it did so we can release 4.2.0.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

So EditTablePlugin suddenly supports cell merging?! Didn't see an enhancement request discussion on Codev about this. Although this would be an useful enhancement (if done properly), please don't do it right now. No wonder we get strange errors with a plugin that (just) used to work (with all its (t)weaks) (more or less) stable out of the box (for years!).

-- TWiki:Main.FranzJosefGigler - 08 Jan 2008

I have never seen a specification that the plugin shouldn't handle merged cells. There was a bug report that it did not handle it. I start to regret that I have spent my time on this plugin.

-- TWiki:Main.ArthurClemens - 08 Jan 2008

Sometimes people specify features without thinking that it breaks something else. Happens to us all. "Be careful what you ask for, you may get it!".

Even if we are giving you critique on this one, please note that we really appreciate all the other improvements you have done to this plugin. They are much appreciated by my users. We had something like 10-15 bugs on this plugin and you have resolved almost all of them plus you were the one that made the move/delete row working. A feature that my users have already told me they LOVE. So no need to regret even if you have to revert this one.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

We need the release stable for the lasts tests and this one is easy to fix.

I already have the code ready. Just working on updating the unit tests.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

Fixed back and unit tests updated.

I will elaborate alternative approaches to the now reverted merge feature on Item4910. There is no need to give up on enabling merged cells. We just need to do it differently.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

Supporting merged cells sounds like an interesting idea. This results in a spec change and it has side-effects, as Kenneth pointed out. We are to close to the release to have these changes made. I am with Kenneth to revert the change back to "not supporting merged cells", unless there is a way to support that in a backward compatible way and it supports emptying cells.

-- TWiki:Main.PeterThoeny - 08 Jan 2008

I have raised a Codev topic TWiki:Codev.CellSpanFeatureForEditTablePlugin with reference to Item4910.

-- TWiki:Main.KennethLavrsen - 08 Jan 2008

My fix had not been properly tested. I had fixed the problem in a function that I had missed was used another place. So I needed to move the fix to the right place.

I also had to reinsert the code that removes the empty space when you edit to avoid annoying the user when he adds data to an empty cell.

-- TWiki:Main.KennethLavrsen - 09 Jan 2008

Some other notes. EditTablePlugin (not because of my changes) now also removes any additional white space before and after the entered text. This means that people can no longer right align and center text with spaces using the plugin. But I think this is worth keeping because to the EditTablePlugin user this is surprising and annoying. I have seen many users goof up because of spaces. When you edit TML you are in geek mode and expect spaces to mean something. But not in EditTablePlugin. Here alignment should be done with TABLE tags alone. So I find this to be an improvement. But I wanted to capture it somewhere in case noone had noticed.

Closing again with fix of fix checked in.

-- TWiki:Main.KennethLavrsen - 09 Jan 2008

The alignment change with spaces used to work, although it wasn't documented anywhere. Why were all these feature enhancements necessary? Sorry Arthur, but the first thing I do is to turn off JAVASCRIPTINTERFACE. I still hope that Crawfords EditRowPlugin will replace EditTablePlugin some day. It's almost there to be fully compatible and it provides much more useful features with a better interface. Did you test EditRowPlugin Kenneth, yet?

-- TWiki:Main.FranzJosefGigler - 09 Jan 2008

Franz you may not like the Javascript interface. But I do. And so do many of my users. If people do not want it they can turn it off once and for all with a setting in Main.TWikiPreferences.

Did your users actually allign by adding spaces in Edit Table?? My users have mostly been confused by it. Especially in text areas where you never know what white space you have where. So I actually see it as a quality that the white space is trimmed.

I did not try EditRowPlugin. Compared to EditTablePlugin very few have used it because it name clashes with EDITTABLE so you have to choose either or. And right now we are a few days from release so I focus on getting EditTablePlugin stable.

Most of the changes done to EditTablePlugin besides the Javascript interface are bug fixes. We had a very long backlog of bugs related to this plugin. And Arthur has taken the task to clean out in that backlog and I am very happy about that.

Unfortunately when you fix one bug you often create another.

-- TWiki:Main.KennethLavrsen - 09 Jan 2008

I'm also happy (and appreciate) that Arthur did push EditTablePlugin to a new level, cause that is a core plugin for doing useful TWiki:Sandbox.TWikiApplications but I still think that EditRowPlugin will be the future, AFTER 4.2 of course.

Yes, bug fixing can be tricky, especially in the case where there is practically no spec. cheers!

-- TWiki:Main.FranzJosefGigler - 09 Jan 2008