• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.
The EditTablePlugin provides some great functionality but doesn't have a convenient way to delete multiple rows or move rows around within a table. I've created some changes that barely touches the existing EditTablePlugin code, but adds a bunch of DHTML for clients that support javascript, and would like to upload them to the SVN.

-- TWiki:Main/ByronDarrah - 14 Mar 2007

Very cool addition. I have really missed this feature for a long time.

Some suggestions and a few details.

First the details

In the EditTablePlugin topic you need to hack the text file after editing so that

  • The author is TWikiContributor
  • The revision is $Rev$

Then some suggestions.

  • I find the icons for move and delete very large and very colourful. I think it would look better and take less real estate making them 16x16 pixels and with transparent background so it will fit better different skins.
  • Insert row is not needed because you can add a row and then move it. But maybe we should consider insert as well?
  • Since this is a default plugin I propose that the new feature is turned off by default so that upgraders do not see any difference. And then you can either selectively turn the feature on or turn it on my default. I would personally turn it on by default smile
  • I had to experiment a bit to find out how the move feature works. One detail that I think people will fight is that if you click the move button and then accidently click the delete button of another row you delete the row and move nothing. Maybe the delete feature should be disabled while you have the move activated. If this is possible.

Finally a question that I could answer myself if I had time this morning.

How does the feature behave if the browser has javascript disabled? Does it gracefully fall back to just not being there or will you see noise?

-- TWiki:Main.KennethLavrsen - 15 Mar 2007

I am working on an update. I will address the most important issues.

AC

I have:

  • Created new icons, in line with TWikiDocGraphics
  • Refactored javascript
    • Added redrawing of alternating row colors after moving/deletion
    • Made delete button disabled when moving. Created a "disabled" delete button image.
    • Added an animated gif as drop targets. Still not the best interface.
    • Added link objects to the buttons to let a mouse hand appear at rollover
    • Moved hardcoded styling to edittable.css
  • Made the javascript interface optional, with the setting JAVASCRIPTINTERFACE turned off by default
  • Refactored the plugin topic to remove references to Mishoo (no longer used)
  • Made the calendar button disappear when no javascript is available (using TWISTY)
  • Added twiki CSS classnames to form objects
  • Fixed the "eating of double newlines" bug: 2 or more newlines (to create a new paragraph) are now kept when the table is saved

And yes, it does fallback gracefully. No js: nothing to see.

Waiting for release, not released yet.

AC

Thanks guys for the attention and help so far! I really like the idea of changing the move button's appearance when a move operation is in progress. Does this perform well on large tables and low-end hardware too?

  • Thanks for the new delete and move icons -- much better than my originals :-).

  • The ability to enable/disable the dynamic editing features is also quite thoughtful, so thanks again. However, I propose that if this goes to release, it should be the enabled default functionality. It's just my guess that more users would be served by having the dynamic table editing on by default, than otherwise. Since it adds to, but doesn't doesn't change the previous functionality in any way, backward compatability is preserved. The only users I think could actually be harmed would be those who use browsers for which the feature is broken, and hopefully we can find and address any such before release.

  • There appears to be a bug in the code that changes the button graphics when a user clicks the move button. At least in Firefox: every time I click the move button, the browser jumps back to the top of the page.

  • Much of the java script code was modified in style. For example, names of functions and variables were changed, comment style was changed, synonym variables added, etc. Was there a reason for this? (For example, is there a TWiki coding style standard for javascript?) The reason I ask is because it makes it a little harder to look at a diff and see what actually changed semantically versus only lexically. It also makes it difficult to merge changes if something like this takes place when two people happen to work off the same revision. For broad changes to code style like this, I'd appreciate a couple of considerations: first, announce the changes you plan to make (possibly by commenting here); second, do two separate commits to the SVN: one that contains only style changes and one that contains any functional changes you also wanted to make. That way we can verify that the style changes did not have a functional impact, and can zero in on functional changes more easily. Hope this sounds reasonable?

  • Some of the new changes do not appear to be related to this particular enhancement. They're probably good changes, but are there other item number topics that should be referenced here and in the SVN commit log? For example:
    • eating of double newlines
    • Removing of references to Mishoo
    • Change the calendar button functionality
    • Addition of CSS classnames to form objects

-- TWiki:Main.ByronDarrah - 17 Mar 2007

Looking over the way alternating row colors are handled in the updated code, I have a couple comments:

  • There appears to be an assumption that there are no more than two alternating colors. So if the databg property of the table has three or more colors, then the colors will appear incorrectly during editing. This can probably be mostly fixed by initially scanning row colors into a list until we encounter a repeated color. It's still not a perfect solution, but I don't think there is one unless we expose data from TablePlugin attributes to the javascript.
  • The code appears to force every cell in the table to have a specific background color, even if it has to use a hardcoded default of #FFFFFF. I think this could mess up cases where the colors are supposed to be inherited from parent elements, including use of the CSS classes, .twikiTableEven and .twikiTableOdd. Haven't tested this yet, but I think we'll want to support some kind of "none" color.

-- TWiki:Main.ByronDarrah - 17 Mar 2007

About default yes or no: the current interface is still not intuitive enough to let it out in the wild. Upgraders will be faced by a new interface and they will have to instruct their users how to work with it.

Yes, I've changed the coding style bringing it more in line with the TWiki javascripts. The coding style is not documented though. I realise now that I didn't take into consideration you would be working along on the code.

I've included more fixes to this enhancement. I've changed the entry summary to include these.

Alternating colors: This can probably be mostly fixed by initially scanning row colors into a list until we encounter a repeated color. This has the problem that colo sequences may have colors listed more than once, for instance "blue, red, blue, green". Edit mode does not have to mimic the view mode. For instance, there is no point in keeping a blue background while the textarea is just white with black text. Alternating colors should enhance readability of the table. So perhaps we could just stick to 2 fixed colors, set in edittable.css.

Revision 13161:

  • Fixed jumping to top bug by not using a link element but by setting the mouse style with CSS.

Revision 13165:

  • Background color is no longer forced.

-- TWiki:Main.ArthurClemens - 17 Mar 2007

  • the current interface is still not intuitive enough -- Yeah, I agree. My original version popped up a dialog when you click on a row to be moved, to tell you what to do. But that was just way too chatty. This way is much more effective to use, but less intuitive. There must be something we could do to make it more user friendly. Got any ideas? Maybe adding some kind of context help or a one-timish dialog?
  • I think it might be a good idea to improve the way color and style updates are maintained. Currently, it looks like every move operation causes the scripts to process every cell in the table, even if a row is only moved by one position, right? I think the function that moves the row could update the styles and colors while it's processing the affected range. For large tables, I think this will yield a pretty good improvement in average case processing time.
  • To Kenneth's point, I've got an idea for how an insert-row feature could be added, with little impact to the existing perl and javascript code. If I get time this weekend, I'll put that in.
  • I'm also toying with the idea of an undo feature. Do you think this would be useful? It's not completely necessary because a user can always cancel their edit session. But if they've made a lot of changes that might be unfortunate.

-- TWiki:Main.ByronDarrah - 18 Mar 2007

Hmm, possible answer to making the interface more intuitive: In addition to the animated move button you provided, how about simply adding a message to the browser's status bar? "To move this row, select a destination". Fancier things like floating tooltips are also possible, but it's a matter of deciding how much messaging is the right amount to communicate this functionality to users. What do you think?

-- TWiki:Main.ByronDarrah - 18 Mar 2007

The confusing thing is you now seem to drop the row unto another one, while in fact you want to claim only the position. It may seem now rows will be swapped. It would be better if you could drop the row in the position between rows.

-- TWiki:Main.ArthurClemens - 18 Mar 2007

We could certainly do that. We could provide a very thin separator between rows, on which users could click to effect a move. It would mean doing away with the animated move buttons though. I'll give that a try. (BTW, have not added the insert-row feature yet. Was too busy this weekend.)

-- TWiki:Main.ByronDarrah - 19 Mar 2007

Yes, the animated targets are no longer necessary then, but the move buttons would need to show a disabled state anyway. Leaves the question what a "cancel move" would be...

-- TWiki:Main.ArthurClemens - 19 Mar 2007

Okay, I've committed a change to this effect. There is now a thin area between each row that is used to specify the move destination.

-- TWiki:Main.ByronDarrah - 20 Mar 2007

I really like this last enhancement. A major improvement in usability.

-- TWiki:Main.KennethLavrsen - 20 Mar 2007

Do you think this feature set now rises to a level of usability such that it could be enabled by default? If not, what else might we be able to improve? (BTW: Thanks again for your time and input so far smile

-- TWiki:Main.ByronDarrah - 22 Mar 2007

The move buttons need to be disabled when starting to move. I think 2 lines of animated gif dots would give a better indication where to move to. The alternating colors could be simplified to 2 default (light blue and white).

-- TWiki:Main.ArthurClemens - 23 Mar 2007

Hi -- I've just been waiting to see if Ken or anyone else would offer comments before I took further action...

So, if I read this right, is the suggestion that the 2 lines of gif dots would surround the row which has been selected to be moved? That is quite doable with a "background-repeat" style. I'll put it in.

Once this is incorporated, is there a good way to get more feedback from anyone other than the three of us? Since I'm advocating turning this on by default, I'd just appreciate any eyeballs and feedback we can get, to help make sure it's thoughtfully implemented.

-- TWiki:Main.ByronDarrah - 29 Mar 2007

I've gone ahead and implemented (my interpretation of) Arthur's suggestion. Moving dashes are now displayed above and below a row that has been selected for moving, and the old move button graphic with moving dashes has been removed.

As usual, I've tested this in Mozilla and IE 6, and would be grateful for reports of compatibility in other browsers, or in fact any kind of feedback at all.

-- TWiki:Main.ByronDarrah - 24 Apr 2007

Since there's been no further comment in a while, I've changed the state to "Waiting for Release".

-- TWiki:Main.ByronDarrah - 11 May 2007

ItemTemplate
Summary Enhance EditTablePlugin with DHTML; fix eating of newlines; graceful fallback calendar button; fix css styling
ReportedBy TWiki:Main.ByronDarrah
Codebase

SVN Range TWiki-4.1.2, Sat, 03 Mar 2007, build 13043
AppliesTo Extension
Component EditTablePlugin
Priority Enhancement
CurrentState Closed
WaitingFor TWiki:Main.ByronDarrah
Checkins TWikirev:13142 TWikirev:13149 TWikirev:13161 TWikirev:13165 TWikirev:13166 TWikirev:13195 TWikirev:13508 TWikirev:14014
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r35 < r34 < r33 < r32 < r31 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r35 - 2008-01-22 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback