Tags:
editing1Add my vote for this tag create new tag
view all tags

EditTablePluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on EditTablePlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the EditTablePlugin bug database.
• See EditTablePluginDevArchive for older discussions.

Development discussion for EditTablePlugin

Wishlist

Please leave this at the top

  • It would be useful if there was a way to restrict a column to accept only numeric values... -- MartinWatt - 24 Nov 2002
  • Following on from the previous item: another cell type that has a numerical label and +/- controls (one or both) to increment/decrement it within predefined range. -- SH
  • Has anybody done any work on supporting justification of cells with the edit plugin? -- JohnRouillard - 25 Jun 2003
  • How can I prevent that %ATTACHURL% is expanded when I edit the table? -- ArthurClemens - 12 Feb 2004
  • I would like to hide the edit button when the user has no edit rights. Should I do this with ConditionalPlugin? -- ArthurClemens - 12 Feb 2004
  • Could there be a new attribute (footerrows) or some such that tells the Add row button to add the row before the footer. -- GaryBeckmann - 02 Apr 2004
  • And since I'm here, could I request a way to have the add rows put the new row in at the beginning of the table (after the header?). -- GaryBeckmann - 02 Apr 2004
  • I second Gary's request to be able to specify that new rows are added at the beginning of the table. I would also like a "delete first row" button. Currently you can only use the table as a stack. With those features you could use it as a list where items were inserted/deleted at either end. -- SamHasler - 08 Apr 2004
  • It would also be nice if there were tools to reorder the table, and delete any row. -- SH
  • Option to have edit controls appear above the table. -- SH -- A coworket just asked for this today -- Main.VickiBrown - 26 Feb 2008
  • Prevent variables used in select lists within edit cells from expanding when editing table. -- SteveRosenthal - 23 Apr 2004
    • But make it defineable for initial values. I've just used format=| select, 1, %SEARCH{...}%| ..." and I want that to evaluate. I've also used %SERVERTIME{}%, but if I was to use %!Y% I wouldn't want it to expand. Prehaps $per should be supported ie "$perY%". -- SH
    • Right. In my particular case, I'm using the form |%EDITCELL{select, 1, %LISTOFSTUFF%}%| and I want %LISTOFSTUFF% to behave the same as if it were in a normal select cell. (Apologies if I'm being redundant.) -- SR
  • Name tables using a name="MyTable" parameter so that you can link to the anchor of a named table and be sure it will always link to the same table ie #edittableMyTable -- SH
    • Agree. In fact, if the tables were named by default (using page-name as base), instead of just numbered, it would probably fix a bug where if you include an EditTablePlugin from another page after an EditTablePlugin on the current page, editing the 1st table over-writes both -- BradVance - Oct 5 2004
  • Disable topic Edit link so that changes to the table can't be accidentally lost, or find a way to make table edits carry over straight into topic edit without a save. (Should this really be a bug?) -- SH
  • Modify so that either a) %INCLUDINGTOPIC% works, or b) %TOPIC% behaves like INCLUDINGTOPIC when you use the %EDITTABLE{include="SomeTopic"}% syntax. -- KM
  • use javascript sorttable for default sorting mechanisim and only fall back to server-side sorting if jscript is not available in the client. -- mhw
  • Show hierarchy using a special column. For example, there is a table of tasks, subtasks and sub-subtasks. Some mechanism to connect parent with children. (For e.g. the way mozilla shows threading in news article). A special column specifies the child's level, and this info is used to create graphics the way TreePlugin does. -- Main.VinodKulkarni - 24 Sept 2004
  • I'd like additional edit-types - specifically the following: -- BradVance - 0ct 5 2004
    1. twikitext - where it gets the actual text of the table (ie - what you see in normal edit mode) thus enabling using twiki variables etc.
    2. renderarea - similar to above, but wrap it in <render> tags (hiding/removing the render tags in edit mode and translating newlines/html-breaks) so that the user can just type in normal twiki text, and have it formatted correctly inside the cell
  • I'd like to be able to set colors in choice fields, e.g. done,broken,etc. right now, this breaks the selection when editting the table. -- SteveWampler - 05 Apr 2005
    • I use the following workaround: %EDITTABLE{format="| text,15 | radio, 1, PENDING, ACTIVE, <span style='background-color: green'>GREEN</span>, <span style='background-color: yellow'>YELLOW</span>, <span style='background-color: red'>RED</span> |"} -- DanDascalescu - 11 Jan 2008
  • How about an Add Column button? -- SeanTSmith - 01 Aug 2005
  • It would be useful (to me at least) to have the option to generate anchors with the task id field, maybe with an anchorprefix="blah" and have anchor #blah1 generated in row 1 (example). This would make it possible to provide jump links at the top of a large topic. -- BrianZablocky - 31 Aug 2005
  • Append-only-mode -- I would like a parameter that caused only the "Add Row" button to be possible and did not allow editing of existing table rows. For one thing, a readonly table (for existing data) could be useful and, for another thing, performance goes downhill fast when converting a largish table into an "all fields are editable" form. -- VickiBrown - 30 Jun 2006
    • For this you can use the CommentPlugin, it can be setup so that on submitting a form, content is appended to a TWiki table. -- PeterThoeny - 30 Jun 2006
    • For performance reasons you might want to look into EditTablerowPlugin, which allows editing of a single row only -- ThomasWeigert - 11 Oct 2006
  • It would be nice if the Edit button could be positioned on the bottom-right side of the table -- JosMaccabiani - 29 Aug 2006
  • Some tables are quite large and it is often desirable to have an edit button at both the top and bottom of the table. Thus a parameter to specify vposition="top, bottom, or both" would be very helpful. -- KeithHelfrich - 22 Jan 2007
    • When editing long tables with many columns, the user can lose track of what header corresponds to each column. I propose to keep the header fixed and have the table in a scrollable div right beneath it. -- DanDascalescu - 11 Jan 2008
  • I have a simple expenses system written using TWiki, it balances bank accounts, cash-in-hand & lets the user enter individual claims. I would like to be able to add rows to the table, but:
    • It has formulae in label fields, which I don't seem to be able to clone into a new row, even using an initial value with escaped characters in the format. This could be a limitation of the plugin, or my error.
    • I have a trailing total row, followed by an "invisible row" (cells with CALC formulae inside html comments) so I'd really like to be able to specify a footer row (or rows) so that a new row is added before them to be included in their calculations -- ChrisHogan - 01 Feb 2007
      • Hi Chris, maybe you could add your code as an alternative to the AccountLedgerApp, or take from what has already been done there -- KH
      • Didn't know about AccountLedgerApp - I'll look at it, because our company accounts have been in an Excel based system for about 15 years (I was laid up with a broken leg & didn't have anything better to do...). It is capable of generating the accounts for a small company (max employees we've had: 10, max turnover £900,000, so it's not a toy), but recently we've been considering moving the lot onto the Internet. My expenses system is a first cut at that. Chris
      • Chris is right, the ability to specify *footer row(s) would be really useful -- KH
  • Why should it take 3 button clicks to add a new row ('edit table', 'add row', 'save table') ? I'm thinking of how nice it would be to have an empty row at the bottom of the table, waiting with a submit button, and reduce the number of steps for adding a new row from 3 clicks to 1. -- KH
  • I would like to be able to INCLUDE select items from another page (or, say, from another table). I can do this now, with a regex and all of the select items on one line, but I'd like to be able to format the select items so I can edit them nicely and then have EditTable slurp them in. * EditTable should observe and respect multi-column table cells (colspan, set either as |||| or |^|^|^|) * enhancement to include parameter to not require _the first %EDITTABLE% in the named topic." If I have more than one unique editable tables on a page and I want them all to get their parameters from a shared location, I currently need one page EDITTABLE definition. Multiple pages increases risk of confusion; I'd like to be able to say something like include="TopicName" section="Section" (ala sections in %INCLUDE%).
  • I would like a format option that uses the value of the previous cell (same column, previous row) as the initial value -- vlb

Done

  • DONE add (or delete) an arbitrary row, anywhere in the table - this would be a killer UI feature for users who really shouldn't be in TML mode. (delete an arbitrary row now exists. Also, rows can be added at the end and moved into position. -- VickiBrown - 11 Aug 2008)
  • DONE It would also be nice if we could get a column on the left with a checkbox, that could be used for deleting all rows checked. -- JohnCavanaugh - 31 Jan 2003
    • Along these lines, I'd like 4 additional columns -- BradVance - Oct 5 2004
      1. Delete Row checkBox
      2. Row Number to indicate current row number
      3. Move Row To pull-down menu, where the menu options are numbers, one for each row in this table, so that you could move it anywhere in the table
      4. Insert Before button to add a row before the current row
    • See EditTablePluginEnhancement, EditTableMergePlugin, for a test implementation of all this stuff. -- GaryOberbrunner - 15 Feb 2005


Updates

The first version is available. At work we have a test result tracking database where this table editor is part of it.

-- PeterThoeny - 06 Apr 2002

A small update aka bug fix was done. Unlike on Windows, Netscape on Unix allows you to paste multiple rows into an edit field. That was going on-to-one into the table cell, breaking the table apart.

Related to this plugin, Codev.SimpleTableEntryUsingForms has the same purpose but is implemented differently.

-- PeterThoeny - 18 Apr 2002

Updated plugin:

  • Added fixed label with format option label. (Option off was suggested by Andrea)
  • Added new changerows="add" parameter. (addonly was suggested by Andrea)
  • Support for variables in included EDITTABLE parameters. (Suggested by Colas)
  • Minor changes; fixed problem with HTML in cells

-- PeterThoeny - 26 Jun 2002

Updated plugin with new helptopic parameter.

-- PeterThoeny - 27 Jun 2002

Updated Plugin version 08 Nov 2002 is posted. This version allows you to place variables in label text (but not yet in other types of fields). This can be used for example to do some spreadsheet calculations or to show a GaugePlugin gauge.

-- PeterThoeny - 09 Nov 2002

Thanks Franz Josef, I added JSCALENDARDATEFORMAT and did some Plugin code cleanup.

In addition, I added CHANGEROWS, JSCALENDARLANGUAGE, JSCALENDAROPTIONS settings.

The CHANGEROWS is now configurable, making the Plugin again backward compatible.

I preinstalled the Mishoo DHTML calendar in the Plugin. Can anyone confirm that it is OK to bundle a LGPL utility with GPLed code?

This topic is getting long, needs to be EditTablePluginDevArchived

-- PeterThoeny - 14 Dec 2003

Posted new version that fixes a bug where the date picker did not work after adding a row.

Also, I got an e-mail reply from Mihai Bazon mishoo@infoiasiPLEASENOSPAM.ro that "I presume it's possible. LGPL basically allows one to even include it in commercial software, so I see no reason why you couldn't use it in TWiki."

-- PeterThoeny - 20 Dec 2003

New Plugin version is posted:

  • Added per cell definition of edit field types with %EDITCELL{}% variable
  • Added headerislabel and editbutton parameters

Enjoy.

-- PeterThoeny - 17 Feb 2004

New version released and installed on TWiki.org:

  • Added QUIETSAVE setting and quietsave parameter
  • Added image for Edit button
  • Added missing gif images reported by Hans

-- PeterThoeny - 28 Feb 2004

New version released on Plugins topic and installed at TWiki.org:

  • Fixed bug where two tables got updated when you edit and save a table included into a topic containing other edit tables

Martin, I reverted your change and added a link to a sandbox topic. This has two reasons: To make it easy for the admin to test the installation and to have all on one place.

-- PeterThoeny - 08 Apr 2004

New version posted in EditTablePlugin topic and installed on TWiki.org. Contains fix where edittable did not work if at the end of a topic. Thanks to CrawfordCurrie for debug help.

-- PeterThoeny - 02 Aug 2004

New Plugin posted, with enhancements needed at my workplace:

  • Added radio buttons and checkbox controls
  • Escaped "|" pipe symbol found in input fields to preserve tables

-- PeterThoeny - 16 Sep 2004


Discussions

It looks like variables in a select menu within an EDITCELL statement are being fully expanded and nop'ing them doesn't work. I don't know if this is a bug, design limitation, or feature request, but it would be great if they followed the same behavior as variables in a traditional select menu. It would keep things cleaner in topic edit mode.

-- SteveRosenthal - 23 Mar 2004

Added a lot of wishlist items including one that might be considered a bug.

Steve: "In my particular case, I'm using the form |%EDITCELL{select, 1, %LISTOFSTUFF%}%|"

EditTablePlugin says you can include vars in selects by using <nop>. Have you tried that?

  • That was the first thing I tried. It keeps the variable from expanding -- completely. In other words, when you go to edit the table and make a selection from the list, you only see the (unexpanded) variable name. -- SR

Is the variable %LISTOFSTUFF% defined with a static list or a %SEARCH{}%? Because I had problems getting a search stored in a variable to work but when I put the search directly in the format definition it worked. Also, if you are using a topic variable it will keep its saved value when previewing. This caught me out once or twice yesterday.

  • It's a static list (a Web preferences variable). -- SR

-- SamHasler - 28 Apr 2004

Well, I've run into a pickle. In an effort to speed up twiki we implemented SpeedyCGI. The speed improvement is amazing. Now I have run into an interesting problem with EditTablePlugin that I am not sure is related to SpeedyCGI - more tomorrow. But here is what I see:

If I edit a small table, all is fine. If, however, I edit a large table (24 rows) EditTablePlugin goes into a "wait forever" mode. Putting the plugin into debug mode renders the following messages:

11 May 2004 - 16:48 - TWiki::Plugins::EditTablePlugin::initPlugin( CUE.ActionPlanAnnualSystemScans2004Q2Tx30 ) is OK
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.DocumentOwner )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.DocumentOwner )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.DocumentOwner )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.FindingsExceptions2004 )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.ActionPlanAnnualSystemScans2004Q2Tx30 )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.ActionPlanAnnualSystemScans2004Q2Tx30 )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE.ActionPlanAnnualSystemScans2004Q2Tx30 )
11 May 2004 - 16:48 - EditTablePlugin::doEnableEdit( CUE, ActionPlanAnnualSystemScans2004Q2Tx30 )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
11 May 2004 - 16:48 - EditTablePlugin::commonTagsHandler( CUE. )
(20 more removed)

Everything appears to be fine until the call to commonTagsHandler after the doEnableEdit. An edit on a small table (4 rows) results in the following debug output: (commented out)

I'm not sure what is going on but we are going to try turning off SpeedyCGI - which wil lbe a real bummer as it speeds up Twiki substantially.

Anyone have any insight into what is happening based upon the above debug output?

Thanks

-- SteveRJones - 11 May 2004

Ok, I've gone back an re-thought this. SpeedyCGI has two mods of OP: Apache_mod or as a #! replacement for Perl. We were using the Apache module and it looked like some buffer size issue which was not modifiable under _mod. So, instead we now "accelerated" each individual cgi script and have yet to have the above re-occur. Bottom-line: SpeedyCGI drastically speeds up TWiki. Highly recommended.

-- SteveRJones - 02 Jun 2004

Is it true that EditTablePlugin won't edit a cell if its formatted as a *header* ? It appears that's the case.

%EDITTABLE{ header="|  *Server*    | *Term Srv Port* | *Interface* | *IP Address*   |  *Netmask*    | *IPMP Group* | *IPMP Flags* |" changerows="on" }%
| *Server*   |*Term Srv Port*|*Interface*|*IP Address*| *Netmask*   |*IPMP Group*|*IPMP Flags*|
| Coarse A | 30 Jan 2004 | .2 |  1.24.75.45  |   /25       |            |            |
| Coarse B | 06 Apr 2004 | .5 |  1.24.79.46  |   /25       |            |            |
|  |  |  |  1.24.75.148 |   /25       |            |            |
| <b>Total Hours:</b> |  | 0.3 |  1.24.75.90  |   /25       |            |            |

When I click "Edit", the "adm1" and "Term Srv" cells in the Server column can not be edited. As a feature, it would be nice if the plugin allowed header type cells to be modified.

  • Spec: Any header cell is automatically a label and can't be edited -- PeterThoeny - 16 Sep 2004

-- SeanONeill - 12 May 2004

Sean, refer to EditTablePlugin and I believe you will find the answer to your question is already there as headerislabel="on/off".

-- SteveRJones - 13 May 2004

I just came across the following bug: If you create a select list with 0 as an option, it appears as a blank space in the list pulldown when editing the table.

-- SteveRosenthal - 27 May 2004

Maybe someone can help me get the following functionality: We would like to use the EditTablePlugin to:

  • Track ToDo tasks for all our projects
  • Each project has a topic, and the ToDo items for each topic should be kept/edited there
  • Have a main ToDoTable topic that shows all ToDo items

Currently I have put an EditTable on each project, that looks like this

Topic What Next Due Date Priority Assigned To Submit To
TestTopic1 Get the EditTablePlugin working 2004-06-10 1.High KenMankoff SomeoneElse

and repeat for each TestTopic2, TestTopic3. Since each topic should have the same EditTable, I am using the include ="ToDoTableTemplate" argument for the EditTable variable.

Then, on the ToDoTable, I try to group all these together with a SEARCH{...} statement.

I have run into the following limitation:

  • The Topic (left-most column) should be a non-editable label based off of INCLUDINGTOPIC. This does not work.
    • I tried to get around this by making it a drop-down list of all possible items using SEARCH{...}, but each time a user edits the table, all rows get their first column reset to the first item returned by the SEARCH{...} query.

Any suggestions how to do this? Should I be using an ActionTracker instead?

-- KenMankoff - 14 Jun 2004

Main.XavierREDON points out that this behavior is fixed in EditTablePluginEnhancement.


Ken, see http://owiki.org/FQP/ for an idea of what can be done using the FormQueryPlugin when combined with the EditTablePlugin.

-- CrawfordCurrie - 18 Jun 2004

http://www.kryogenix.org/code/browser/sorttable/ - A short javascript which allows a table to be sorted by clicking on the column headings without another trip to the server. Very nice. Just add a fallback mechanism for no-js browsers and we can have our cake and eat it too.

-- MattWilkie - 20 Jun 2004

I am interested in a simple feature that will help "select" options list to be read from a topic, exactly like what TWikiForms does. (No, not the usual include syntax, but an include within select such as select, 3, include(ListOfOptions).). Though this could be done by using SEARCH, I am looking for a clean approach.

In related note, I am also looking for a capability for more than one options to be selected and added to table, probably separated by ';', with any rendering such as BR.

Are there any alternatives?

-- VinodKulkarni - 06 Jul 2004

What happened to bin/viewauth? Edit table uses this, but it is no longer in the twiki distribution. Or should I upgrade EditTablePlugin?

  • viewauth is shipped with the distrubution. It is not in SVN to avoid out of sync files. -- PeterThoeny - 16 Sep 2004

-- ArthurClemens - 08 Jul 2004

I think I have managed to get $percnt syntax to work such that the Select option variables are dynamically evaluated. This code was very much there, but for a nasty bug. Here is the patch:

***************
*** 546,553 ****
          $size = 1 if $size < 1;
          $text = "<select$style name=\"$theName\" size=\"$size\">";
          $i = 2;
!         while( $i < @bits ) {
!             $val  = $bits[$i] || "";
              $valExpanded  = $bitsExpanded[$i] || "";
              if( $valExpanded eq $expandedValue ) {
                  $text .= " <option selected=\"selected\">$val</option>";
--- 548,555 ----
          $size = 1 if $size < 1;
          $text = "<select$style name=\"$theName\" size=\"$size\">";
          $i = 2;
!         while( $i < @bitsExpanded ) {
!             $val  = $bitsExpanded[$i] || "";
              $valExpanded  = $bitsExpanded[$i] || "";
              if( $valExpanded eq $expandedValue ) {
                  $text .= " <option selected=\"selected\">$val</option>";
I used syntax: %EDITTABLE{format="|text, 20|select, 1, $percntINCLUDE{TestTopic2}$percnt, localoption1, localoption2|"}%

Could someone verify if it breaks anything else?

-- VinodKulkarni - 22 Jul 2004

I haven't been able to find anything documented about this - but say I set up a 'textarea' to accept random text which may eventually recieve a pipe somewhere in it

(e.g. "|")
, it will destroy the table. Any workarounds for this?

-- AaronSebastian - 27 Jul 2004

Pipe symbol: Plugin should escaped it. Looks like a bug.

No time yet to incorporate other changes...

-- PeterThoeny - 02 Aug 2004

Since EditTablePlugin seems to slow down as you add more rows, I have found that adding a "Add multiple rows" button was well appreciated by my cow-orkers. I restrict to at most 10 rows to avoid pain. I am posting the diff here though the line numbers might be off since I have already hacked it otherwise.

diff new old
189,190c189,190
<                } elsif( $query->param( 'etaddonerow' ) ) {
<                    # [Add one row] button pressed
---
>                } elsif( $query->param( 'etaddrow' ) ) {
>                    # [Add row] button pressed
194,204d193
<                } elsif( $query->param( 'etaddrows' ) ) {
<                    # [Add num rows] button pressed
<                    my $numRows = $query->param ( 'etnumrows' );
<                    if ( ($numRows =~ /[0-9]+/) && ($numRows < 11)) {
<                        # add atmost 10 for sanity check
<                        $cgiRows += int $numRows if( $cgiRows >= 0 );
<                    } else { #default add one
<                        $cgiRows++ if( $cgiRows >= 0 );
<                    }
<                    $doEdit = doEnableEdit( $theWeb, $theTopic, 0 );
<                    return unless( $doEdit );
468,470c443
<             $text .= "$preSp< input type=\"submit\" name=\"etaddonerow\" value=\"Add one row\" />
\n";
<             $text .= "$preSp< input type=\"text\" name=\"etnumrows\"  value=\"1\" />\n";
<             $text .= "$preSp< input type=\"submit\" name=\"etaddrows\" value=\"Add rows\" />\n";
---
>             $text .= "$preSp< input type=\"submit\" name=\"etaddrow\" value=\"Add row\" />\n";

-- KiranBondalapati - 03 Aug 2004

I seem to be unable to add a second row. Not experienced with debugging twiki, but with some pointers I might be able to help. When I click "add row" a request is sent but the server (apache/FC1) never responds. Try here:

http://www.dplinux.org/twiki/bin/viewauth/TWiki/TestPlan#edittable2

Thanks

PS: it actually returns an error: premature termination of script headers

-- AntonioPiccolboni - 13 Aug 2004

Just a little enhancement which is nice and usefull for a Todo list (for example) edit table.

I have added two possibilities : move or protect from edit a row.

  • Protect a row :
    • Set option keywordlock to match cell content of rows to protect from editing.
  • Move rows :
    • Set option keywordmove to match cell content of rows to move and set moverows option to tell the way you want rows to be moved :
      • move matching rows to the end of the table,
      • move matching rows to a (non-editable) table below current one,
      • move matching rows to the end of Topic (in this case, you can also have a table header).

See EditTablePluginMoveRows, to get a better understanding. In this example, I have activated options :

  • keywordlock=LOCKED
  • keywordmove=CANCELLED|FINISHED
  • moverows=topicend

Any cell filled with text CANCELLED or FINISHED will cause corresponding row to be moved according to the selected move action (no move is done if action is not correct). Any cell filled with text LOCKED will not be editable via editable.

I have uploaded the patch against 07 Apr 2004, it's small, only a few lines added or changed. Hope You all appreciate it wink

-- PatrickNomblot - 18 Aug 2004

There is a bug in the current EditTablePlugin, see EditTablePluginAnomolies.

-- MattWilkie - 07 Oct 2004

BUG Spreadsheet functions get expanded. The following example worked in the Beijing TWiki release, but does not in the Cairo (current) release:

%TABLE{cellpadding="3"}%
%EDITTABLE{ changerows="on" header="on" }%
| *Label1* | *Label2* | *Label3* |
| data | data | data |
| data | data | data |
| *Subsection* |  |  |
| data | data1 | data |
| data | data | data |

Course Date Hours
Coarse A 30 Jan 2004 .2
Coarse B 06 Apr 2004 .1
     
Total Hours:   0.3

Editing this table via the Edit button will whack the %CALC% function.

-- MartyBacke - 01 Nov 2004

Is it possible to %INCLUDE% a http link in a table? The contents of the http link are displayed, but the embedded �select� function for a different column appears broken, when editing. This is an example of what I�m trying to do:

%EDITTABLE{ format="text, 15, nul | text, 15, nul | text, 15, nul | select, 1, start, not| text, 15, nul  |text, 16, nul |" | changerows="add" | headerislabel="on" }%
| *Machine* | *Test* | *Build* | *Tests* | *Comment* | *URL* |
| cherry | Test | 1119 | start | out | %INCLUDE{"http://X.X.X.X/test/wiki/cherry"}% |

-- ScottCarroll - 21 Nov 2004

With any luck, the changes in EditTablePluginEnhancement address my problem -- please see the note above concerning %INCLUDE% of an http page not rendering correctly. As I said above, %INCLUDE% appears either broken, its function is not well understood, or this is a limitation.

-- ScottCarroll - 24 Nov 2004

The schema specification for EditTablePlugin appears to duplicate the functionality of the TWikiForm; it occurs to me that merging the two would bring about greater consistency.

-- MartinCleaver - 02 Jan 2005

Peter, I just saw now (shame on me) that you set the default date to a non-standard one (YYYY/MM/DD). I would rather advocate MovingToIsoDate format, which is a standard, unmistakable format (and sortable). Opinions?

-- ColasNahaboo - 06 Jan 2005

I packaged ColasNahaboo's use of JSCalendar with minor modifications to leverage JSCalendarContrib in JSCalendarAddOn. The update to EditTablePlugin below leverages JSCalendarAddOn rather than duplicating the JSCalendar needlessly.

-- ThomasWeigert - 07 Feb 2005

ChangeProposalFormDefect was caused by peculiarities in the way this plugin expands variables.I was able to fix it by changing the variable definitions but it would make this plugin infinitely more useful.

When going into edit mode I want it to expand variables so that I can put EDITCELL definitions in variables, but when it saves the table again I would like it to save the variable name again, not it's evaluated content.

I also want to be able to use variables within variables. That is I want to be able to do the following:

   * Set CATEGORIES = one, two, three
   * Set MYEDITCELL = %EDITCELL{checkbox, 4, %CATEGORIES%}%

| *Categories* | %MYEDITCELL% |

(This is so that I can use %CATEGORIES% in a html form for initially populating the table on topic creation. That way the list is defined in one place.)

Currently it expands %MYEDITCELL% to get the editcell definition, but it doesn't expand %CATEGORIES% and treats it as a single checkbox. When the page gets rendered you end up with a single checkbox for "one, two, three".

-- SamHasler - 14 Feb 2005

I'm seeing the same as MartyBacke is mentioning, is this resolved or circumventable by some of these EDITCELL modifications going?

-- OleCMeldahl - 07 Mar 2005

FYI: I was going to post a bug refering to EditTablePlugin the current stable release of twiki. However, this bug did not show up here on twiki.org, so i removed my posting.

However my simple example modified another example on the this page, when hiting edit and save on my table example. See r1.178-r1.177 for details.

Here is the example I used which created the issue mentioned. I didn't check again to avoind other changes on this page though.

Label1 Label2 Label3
data data data
data data data
Subsection
data data data
data data data

-- WolfgangAlper - 14 Mar 2005

is there a way to have the calender displayed all the time, not just when editing?

-- MattWilkie - 10 May 2005

Does anyone know if its possible to hide the table while still allowing the EDIT button to appear? I often use the ChartPlugin and would love to be able to combine a displayed chart with a hidden EDITTABLE. Then, clicking on the EDIT button would pop up the EditTable window, allowing me to quickly change the values displayed in the chart.

-- SteveWampler - 22 Jun 2005

Interesting idea, I guess it should be possible to do this by some CSS wizardry, but I'm pretty sure neither TablePlugin nor EditTablePlugin have proper support for this yet.

Steve's proposal sounds like yet another useful application of the lately proposed twisty mechanism.

-- FranzJosefSilli - 22 Jun 2005
-- FranzJosefSilli - 29 Aug 2005

Well, I didn't think so, but one can always hope. I can hide the TablePlugin (or EditTablePlugin) easily enough by embedding it in an HTML comment, but would have liked to show the EDIT button. Thanks for the response.

-- SteveWampler - 22 Jun 2005


EditTablePlugin versions are out of synch. CVS reports latest version as 07-Apr-2004, Plugins.EditTablePlugin is 16-Sep-2004, and Develop is 1.024 and appears to have branched from EditTablePlugin one rev back from current.

Q: Does the develop version incorporate the change from the Plugins web and just not note it?

Q: Where is the develop version hosted?
A: Ah, it is now in the DEVELOP branch in svn

-- MattWilkie - 06 Jul 2005


Can anyone help out with this? I've got a topic in which I want to have the user to be able to generate a table by providing the table name, then pressing a 'create' button. I've created a template in the User Templates topic that has:

%TMPL:DEF{PROMPT:Stable}%<br />
|  *Name* | <textarea cols="80" rows="1" name="Stable_name"></textarea>  |
| <input type="submit" value="Create new table" /> ||
%TMPL:END%

%TMPL:DEF{OUTPUT:Stable}%
%POS:BOTTOM%
%BR%%BR%
---++ %URLPARAM{"Stable_name"}%
%BR%
%TABLE{ cellpadding="1" headeralign="left" tableborder="0" columnwidths="400,700" databg="#F3F0F0,#EAEAEA" headerbg="#cccccc" }%
%EDITTABLE{ changerows="off" editbutton="Update table" format="|label|text, 80|" }%
|*TITLE*|%EDITCELL{ "label" }%|
|Data |test data|
%TMPL:END%

I then use COMMENT in the topic itself to allow the user to create multiple tables of the same type on demand:

%COMMENT{ type="Stable" }%

When I run this, the table is created ok, but the EDITTABLE command seems to get parsed into:

<a name="edittable1"></a>
<form name="edittable1" action="http://x.x.x.x/twiki/bin/viewauth/Sandbox/TestTopic2#edittable1" method="post">
<input type="hidden" name="ettablenr" value="1" />
<input type="hidden" name="etedit" value="on" />

Whenever the user presses any of the Edit buttons associated with a generated table, it jumps to the first table in the topic and edits that. Any ideas how to stop this behaviour so the user edits the correct table?

Many thanks in advance.

-- HelenJohnstone - 12 Sep 2005

When I add a row, the table is re-rendered with the new empty row but the top of the table appears on the screen. Hence I have to scroll down to the empty row each time. That's a bit tedious when there are a few hundred rows. Does anyone know how to have the bottom of the table displayed when a new row is added?

-- DavidBaker - 28 Nov 2005

How do maintain formatting in the rows themselves? I'd like to have some of my columns centered, not just right aligned?

-- BrianBeaudet - 10 Feb 2006

Use a %TABLE{}% directive, located above the %EDITTABLE{}%. See TablePlugin.

-- PeterThoeny - 10 Feb 2006

I have made a small patch which allows you to set some of the edittable design in a css stylesheet, mainly the defintion of background colors in even and odd rows... the color was hardcoded before:

<     if ($theRowNr % 2) {
<       $style = "Even";
<     }
<     else {
<       $style = "Odd";
<     }
---
>     $style = " style='background:#e8e8e8'" if ($theRowNr % 2);
424c419
<         $text = "<select class=\"editTable$style\" name=\"$theName\" size=\"$size\">";
---
>         $text = "<select$style name=\"$theName\" size=\"$size\">";
466c461
<         $text .= "<input type=\"hidden\" name=\"$theName\" value=\"$theValue\" />";
---
>         $text .= "<input$style type=\"hidden\" name=\"$theName\" value=\"$theValue\" />";
475c470
<         $text .= "<textarea class=\"editTableTextarea$style\" rows=\"$rows\" cols=\"$cols\" name=\"$theName\">$theValue</textarea>";
---
>         $text .= "<textarea$style class=\"editTableTextarea\" rows=\"$rows\" cols=\"$cols\" name=\"$theName\">$theValue</textarea>";
508c503
<         $text = "<input class=\"editTableInput$style\" type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\"/>";
---
>         $text = "<input$style class=\"editTableInput\" type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\"/>";

All you need to do after applying the patch is defining editTableInputOdd, editTableInputEven, editTableTextareaEven etc. in your css file with your custom background color.

-- PeterLohmann - 13 Feb 2006

I'm having an odd problem with the edit table plugin where it replaces the row headers with names of a previously edited table. I posted a support question at EditTableReplacesHeaders .

-- JoelOnofrio - 22 Feb 2006

Anyway to have a summary row (or two) that always stays on the bottom and won't be moved when the rest of the table is sorted? I'm trying to create a dynamic table that has such a thing and use the summary data for charting. So this table would be using EditTablePlugin, SpreadsheetPlugin and ChartPlugin. My main concern it just the non-sortable rows.

-- BrianBeaudet - 30 Mar 2006

You can "stick" header and footer rows with the TablePlugin, it has headerrows and footerrows parameters.

-- PeterThoeny - 30 Mar 2006

I've added a feature for moving rows around quickly and conveniently. Select a row by clicking on it's row label, then click the "Move row" button, and select a target position. The row is instantly moved. The change happens entirely on the client side, so nothing is sent to the server until and unless you submit the table using the normal controls.

In order for this to work, your rows do need row labels. So for example, format one of your table columns as "label, 0, %EDITCELL{row, 0}%", or something similar. That column can then be used to click-select rows for moving or deleting (tested in IE 6 and Firefox 1.5).

If interested, please try my patched version of the plugin: TWiki-4.0.2-EditTablePlugin-MoveRowDynamically.tgz Please note, this patch requires TWiki 4.0.2.

Just unpack it in the top-level TWiki directory, and please let me know of any compatibility issues you discover. It Changes only two files and adds a third. You can back out the change by restoring the original files.

-- ByronDarrah - 24 May 2006

Interesting feature. What happens if JavaScript is disabled? Does it degrade nicely?

-- PeterThoeny - 25 May 2006

Nope. It will degrade pretty horrbibly :-). In getting this to work I ended up having to convert the delete row function to a script hook as well, so without script support, both move and delete features go away. It should not cause any tables to corrupt or anything like that, you just won't be able to move or delete rows.

Do you think something like this could have a chance to be accepted into the main EditTablePlugin development? (Perhaps if we make it a little more graceful for scriptless clients?) If not, then I'll be happy to rename this modified version of EditTablePlugin so that it can be deployed without concern over getting creamed by a future EditTablePlugin update. (Maybe that's the way to go anyway -- I could just call it "DynamicTablePlugin" or some such, and assert that Javascript support is required, so anyone needing to support scriptless clients should not use it? Hmm.) Interested to hear what you and others think.

-- ByronDarrah - 02 Jun 2006

I'd say if it is done so that it degrades nicely without JavaScript it is better to take it into this Plugin codebase. Make sure to work with the latest version from the TWiki 4 SVN branch, https://svn.twiki.org/svn/twiki/branches/TWikiRelease04x00/twikiplugins/EditTablePlugin/

ReadmeFirst has more on how to get involved in using SVN for Plugin development.

-- PeterThoeny - 03 Jun 2006

Okay, thanks for the advice. I'll work on the graceful degradation and investigate SVN development.

-- ByronDarrah - 06 Jun 2006

I suggest a little (in code changes) but very usefull enhancement to editable (with patch here against DAKAR 4.0.3) . We use it in our TWiki (>500 users) since 2002 without any problem, sure that many people would appreciate it :

We added two possibilities :

  1. protect a row from editing if it contains a given keyword
  2. move (at the end of topic or of table) a row containing given keyword

  • Protect a row :
    • define option keywordlock to match cell content of rows to protect from editing.
  • Move rows :
    • define option keywordmove to match cell content of rows to move and set moverows option to tell the way you want rows to be moved :
      • move matching rows to the end of the table,
      • move matching rows to a (non-editable) table below current one,
      • move matching rows to the end of Topic (in this case, you can also have a table header).

See EditTablePluginMoveRows, to get a better understanding. In this example, I have activated options :

  • keywordlock=LOCKED
  • keywordmove=CANCELLED|FINISHED
  • moverows=topicend

Any cell filled with text CANCELLED or FINISHED will cause corresponding row to be moved according to the selected move action (no move is done if action is not correct). Any cell filled with text LOCKED will not be editable via editable.

I have uploaded the patch against TWiki DAKAR 4.0.3, it's small, only a few lines added. I Hope You all appreciate it and accept to add this feature in standard EditTablePlugin wink

Patch for EditTablePlugin/Core.pm

-- PatrickNomblot - 28 Jun 2006

Thanks Patrick for the patch, this looks like a useful enhancement. I did not understand how it works until I looked at the raw text of EditTablePluginMoveRows. Could you provide documentation that we can take into the EditTablePlugin?

-- PeterThoeny - 28 Jun 2006

Byran: are you still working on your enhancement? I think it's great, and I'm sure may others agree. I'd love to see your feature become an integral part of the plugin.

-- StephanMaasen - 15 Sep 2006

I have updated EditTablePluginMoveRows minimal doc, My english is not very good, you may fix it if you like.

Note that mechanims could be base on

  • keywordmoveafter
  • keywordmoveend
  • keywordmovetopicend

rather than keywordmove + moverows parameters.

It could allow 3 move possibilitees for one edittable.... as you prefer.

-- PatrickNomblot - 04 Oct 2006

I created a new column-type "color" that provides a dhtml color picker (fills in the hex value of the color). It uses ColorPickerContrib together with this patch:

--- lib/TWiki/Plugins/EditTablePlugin/Core.pm   2006-07-29 11:38:43.000000000 +0200
+++ ../wiki/lib/TWiki/Plugins/EditTablePlugin/Core.pm   2006-10-27 20:55:19.000000000 +0200
@@ -279,6 +279,10 @@
         unless( $@ ) {
             TWiki::Contrib::JSCalendarContrib::addHEAD( 'twiki' );
         }
+        require TWiki::Contrib::ColorPickerContrib;
+        unless( $@ ) {
+            TWiki::Contrib::ColorPickerContrib::addHEAD();
+        }
     }
     $text .= "$preSp<noautolink>\n" if $doEdit;
     $text .= "$preSp<a name=\"edittable$theTableNr\"></a>\n";
@@ -525,6 +529,28 @@
         $text .= "<textarea$style class=\"editTableTextarea\" rows=\"$rows\" cols=\"$cols\" name=\"$theName\">$theValue</textarea>";
         $text .= saveEditCellFormat( $cellFormat, $theName );
 
+    } elsif( $type eq 'color' ) {
+        $size = 7 if( !$size || $size < 1 );
+        $theValue = TWiki::Plugins::EditTablePlugin::encodeValue( $theValue ) unless( $theValue eq '' );
+        $text .= CGI::textfield(
+            { name => $theName,
+              id => 'id'.$theName,
+              size=> $size,
+              value => $theValue ,
+              style => "background:$theValue;"});
+        $text .= saveEditCellFormat( $cellFormat, $theName );
+        eval 'use TWiki::Contrib::ColorPickerContrib';
+        unless ( $@ ) {
+            $text .= CGI::image_button(
+                -name => 'cpicker',
+                -onclick =>
+                  "return cp_show('id$theName');",
+                -src=> TWiki::Func::getPubUrlPath() . '/' .
+                  TWiki::Func::getTwikiWebname() .
+                      '/ColorPicker/colorpicker.png',
+                -alt => 'ColorPicker',
+                -align => 'MIDDLE' );
+        }
     } elsif( $type eq 'date' ) {
         my $ifFormat = '';
         $ifFormat = $bits[3] if( @bits > 3 );

Use like this: %EDITTABLE{format="|color, 10|"}%

-- FlavioCurti - 27 Oct 2006

We can take this into the package, but I suggest to make this enhancement: Load the Perl module conditionally, only if needed (use a global flag that tracks if tried to load before). Graceful fallback: Reading the code, it looks like there is already a fallback to a simple text box if the module is not loaded, so that is good.

-- PeterThoeny - 27 Oct 2006

Exactly, if the module is unable to load, you just get a input box.

The module loading code is shamelessly stolen from the JSCalender add-on. So I'm not exactly sure how you want me to test. Do you want to have a flag set when it couldn't load the module, so it doesn't try to load it several times?

Rg. the color picker itself, atm it only works using DHTML so it needs a recent Browser. I haven't tested it on any other browsers except Firefox.

Thank you for your positive feedback!

-- FlavioCurti - 28 Oct 2006

The color picker is much less likely to be used than the date picker, hence the color picker Perl module and javascript should only be loaded if there is an edit cell of type color, and only once. Hence the suggestion for the global flag.

-- PeterThoeny - 28 Oct 2006

I'm not sure if this is the right place to ask, but We'd like to be able to have an open edit table and then have the ability to enter text at either the table or a comment field at the bottom of the page. By saving either one, modifications to both should be saved... any ideas? We'd be willing to support someone doing this depending on cost.

-- ArtMorales - 21 Nov 2006

You can combine the EditTablePlugin and CommentPlugin so that you can easily add a table row at the end. See example at Sandbox.EditActionItems. Does that what you need?

-- PeterThoeny - 21 Nov 2006

Sorta. Ideally, the comment would be at the end of the page and not part of the table. We have many tables on one page with slightly different columns (so there are multiple places to edit). The user should be able to enter a comment at the same time they are editing the table and have both fields save by a save/addcomment action. This may be already close to what I need (the comment gets added even if the table is being edited, but I'm not sure how it would behave with mutliple tables. I'll take a look at the code and see how it is done... Alternatively, the simpler solution would be to modify the order/actions so that the "add comment" button closes and saves the page thus saving the edited table at the same time as the comment is added.

-- ArtMorales - 21 Nov 2006

Actually, It does not do what I need... the problem is that I need the user to put data in both the specific table and the comments at the end of the page... when one of the buttons is pressed to save either one, both entries should be saved at once...

-- ArtMorales - 25 Nov 2006

And so I continue my monologue... I guess one solution is to have two browser windows open, one editing the table and the other one in view mode. I should then be able to type on both and have the changes "merged" (easy, since they are not on the same section...). Thoughts?

-- ArtMorales - 27 Nov 2006

Okay, I know it's been a few months, but better late than never:

Peter wrote: Byran: are you still working on your enhancement?

Yes, I've finally circled back to that. I have a nicer version than my original EditTablePlugin mod for letting users dynamically manipulate table rows, plus it has no impact on non-javascript users. There is less impact to the Core.pm code than before too, so I'm optimistic that existing functionality is fully preserved.

I've requested access to the SVN to check in the changes.

-- ByronDarrah - 01 Mar 2007

For now, here's a link to the modified version. It should be a drop-in replacement for EditTablePlugin on probably any 4.x version of TWiki.

EditTablePlugin-Dynamic.tgz

-- ByronDarrah - 01 Mar 2007

Byron, thanks for working on this! Please make sure there is a graceful fallback for those agents where javascript is turned off.

-- PeterThoeny - 05 Mar 2007

Yes, there is. If javascript is turned off or not supported, the experience should be exactly as if my changes never happened. Tested in IE 6 and Firefox 1.5. (I think Sven is on vacation or something though, so I'm sitting tight until he's available to help me with checkin access.)

-- ByronDarrah - 08 Mar 2007

Okay, dynamic table manipulation checked in to SVN. I'll be especially interested to hear of any incompatibilities with browers I haven't tested (Opera, Konqueror, Safari...).

-- ByronDarrah - 14 Mar 2007

Bug Reports

The plugin runs too late. If you put TWikiVariables in a table cell, say %MAINWEB%.ThomasWeigert, this will be expanded on the next edit into Main.ThomasWeigert, and the expanded version is saved into the topic, which is not what the user entered. I believe the plugin should be run from beforeCommonTagsHandler, not commonTagsHandler, to avoid these problems.

-- ThomasWeigert - 07 May 2005

The definitions for the input controls should match those in TWikiForms. It is confusing and unnecessary to have a different schema here. Note that EditTablerowPlugin uses the scheme in TWikiForms.

-- ThomasWeigert - 08 May 2005

I don't know if this is listed somewhere, but would it be possible to remove the dependence on spaces around "," in the select definition? Currently, if there is a space between the value and the next comma, the value is not recognized properly. Example : select, 1, 0, .2 , .5 , 1, 2 In this case, if the table had values of .2 or .5 in that field, edittable would set the value back to the default when editing the table thus losing the previous state. Basically, the trailing spaces are being considered part of the value in the select definition.

I think this could be fixed by doing a split(/\s*,/s*/,$format) instead of split(/,\s*/,$format)

-- AndrewBarber - 01 Dec 2005

While using textarea,if table has more than 10 record, it will hang

-- RexXie - 27 Dec 2005

Within the latest Core.pm a comment is added to the output inside handleTableEnd() (it reads "<!-- /editTable -->") and as far as I can tell this is not used as some kind of bread crumb for later processing.

Doing this causes problems when using %INCLUDE{}% if one wishes to include a topic for calculation functionality only, i.e., an %INCLUDE{}% inside comments. This results in nested comments which causes problems with some browsers.

-- MikeMuir - 14 Mar 2006

Will, the version you posted no longer has the settings for JSCALENDARDATEFORMAT, JSCALENDARLANGUAGE and JSCALENDAROPTIONS. Is this functionality lost or just not documented? See doc diff.

-- PeterThoeny - 07 Apr 2006

Thomas wrote "The plugin runs too late. If you put TWikiVariables in a table cell, say ThomasWeigert, this will be expanded on the next edit into ThomasWeigert, and the expanded version is saved into the topic, which is not what the user entered. I believe the plugin should be run from beforeCommonTagsHandler, not commonTagsHandler, to avoid these problems."

This comments was never followed up. The fact that you cannot use TWiki variables in EditTablePlugin really limits its use. Will Thomas' proposal have any negative effects?

-- KennethLavrsen - 07 Jun 2006

It would be nicer if variables would not get expanded. For compatibility, possibly with a switch to expand / not expand variables.

-- PeterThoeny - 07 Jun 2006

This Plugin does not support TWiki formatting like bold and colors; if a cell is bold or colored, the cell is not editable

-- FerdinandGassauer - 08 Jun 2006

This is actually a feature. Enclosing a whole cell in asterisks turns the cell into a heading. Headings are not editable. If you want bold cells you can write | <nop> some text | or | <b>some text</b> |

-- PeterThoeny - 08 Jun 2006

JS date picker does not work for me with FireFox 1.5.0.4 (first table at EditTablePluginTesting for example). JSCalendarContrib demo works ok.

No such problem with IE

-- NikolayUgarov - 08 Jun 2006

Are you using the latest version of JSCalendarContrib, Nikolay? (See Bugs:Item2054).

-- SteffenPoulsen - 08 Jun 2006

Thanks Steffen. I used the tip in that bug report -- remove line beginning with "z-index:1;" from pattern layout.css -- to fix this problem (browser Camino 1.0.2) . -- PaulHenryDavis - 13 Jul 2006

I am having a problem getting authentication working with the EditTablePlugin against LDAP. Everything else in my TWiki installation is working as expected; it is just EditTable that is giving me troubles. Here are my details:

TWiki Version: 4.0.1

EditTablePlugin Version: Tried with what came with TWiki 4.0.1. Also tried upgrading to the 4/7/2006 release.

Authentication Details: {LoginManager} = none {PasswordManager} = TWiki::Users::HtPasswd::User {Htpasswd}{FileName} = /var/lib/twiki/data/.htpasswd {Htpasswd}{Encoding} = crypt .htaccess

AuthLDAPAuthoritative on
AuthLDAPURL ldap://host.server.com:389/cn=Users,dc=domain,dc=com?sAMAccountName?sub?(objectClass=*)
AuthLDAPBindDN cn=Administrator,cn=Users,dc=domain,dc=com
AuthLDAPBindPassword mypassword
AuthName "Please log in with your Windows login"
AuthType Basic

<FilesMatch "[^/]*\.html$">
                SetHandler blabla
                allow from all
</FilesMatch>

<FilesMatch "configure.*">
                #require user "{Administrators}"
                require user Administrator
</FilesMatch>

<FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|.*auth).*">
                require valid-user
</FilesMatch>

<FilesMatch ".*">
        allow from all
</FilesMatch>

-- AdamEllis - 20 Jun 2006

Do you have a viewauth in your bin directory? It is identical to the view scribt, it can be a symbolic link.

-- PeterThoeny - 27 Jun 2006

How can I force a new revision of the Wiki document with every "save" of an edited table?

-- FerdinandGassauer - 06 Jul 2006

I do not see an easy way to do that. The save script has a forcenewrevision, TWikiScripts. However, the EditTablePlugin does the read-modify-save topic action during viewauth.

-- PeterThoeny - 06 Jul 2006

Peter - I do have a viewauth in my bin directory. It is not a symbolic link, but is the same size and timestamp as the view script. As a side question, is it possible to edit the EditTablePlugin somewhere to disable authentication entirely? My users must authenticate to see the webs anyway.

-- AdamEllis - 10 Jul 2006

From the .htaccess you posted above it looks like view is not authenticated. Since you are saying that users must authenticate to see the webs, is it possible that the ldap auth is done at a higher level in the Apache config file? In any case, you could change all occurences of viewauth to view in the EditTablePlugin code. Hower, it is better to check your config for proper auth of the viewauth script.

-- PeterThoeny - 10 Jul 2006

If your table is similar to

%EDITTABLE{format="|text|text|"}%
| *Name* | *Ammount* |
| sopan | 1044 |
| Sarika | 224 |
| Total | %CALC{$SUM( $ABOVE() )}%  |

When you press "Edit" button of table,

%CALC{$SUM( $ABOVE() ) }%
gets expanded to addition of numbers. So if you make changes numbers in the above rows next time, formula does not work.

Small changes in SpreadSheetPlugin can solve this problem.

In SpreadSheetPlugin's Calc.pm code, just add following lines in doCalc subroutine (Line number: 135):

$query = TWiki::Func::getCgiQuery();
my $frtable = $query->param('etedit');
if ($frtable eq "on" ) { return "%CALC{".$text."}%"; }

Also you need to add $query in

use vars qw(.....); 

-- SopanShewale - 11 Jul 2006

Thanks Sopan. I posted a cross-reference in SpreadSheetPluginDev since it needs to be fixed there.

-- PeterThoeny - 11 Jul 2006

We see a problem when we click on the field name to sort a column. The error message ?template=oopsleaseconflict;def=active;param1=Mai...

Conflict
Attention 

 Try again to see if PeterJones has finished editing yet. 

Edit anyway   to edit the topic anyway. 


We are able to add/delete rows without this conflict message. Could this be a bug?

-- PeterJones - 12 Jul 2006

Sounds like. Please file a bug report in Bugs:EditTablePlugin, describing the details.

-- PeterThoeny - 14 Jul 2006

I am unable to file the bug report on develop.twiki.org. I can not register as the confirmation email is never sent.

-- PeterJones - 18 Jul 2006

You cannot register on develop.twiki.org, please login with your twiki.org account.

-- PeterThoeny - 18 Jul 2006

If I enter the twiki.org username/password nothing happens. I am again presented with the login page.

-- PeterJones - 24 Jul 2006

SvenDowideit, could you please check? PeterJones has a TWiki.org account since Jan 2005.

-- PeterThoeny - 24 Jul 2006

You always could use TWikiGuest/guest to file a new issue item on Bugs till Sven has checked/replicated .htpasswd on develop.twiki.org.

-- FranzJosefSilli - 24 Jul 2006

Any ideas on why I'm having trouble InstallingEditTablePlugin on CairoRelease would be greatly appreciated. Thanks.

-- KeithHelfrich - 25 Jul 2006

There have been many complaints that the plugin translate the TWikiVariables when you save the table.

You cannot at all use TWikiVariables without having them "destroyed" when you save.

I cannot imagine when anyone would want to enter a TWikiVar and then have it translated to static text when clicking save. Makes no sense at all.

I tried to alter EditTablePlugin.pm. Very simple change. Change sub commonTagsHandler { to sub beforeCommonTagsHandler{

And then it works exactly like I want it. I have not found any examples that anything breaks from this. I propose that we implement this change. I can do it and upload a new version unless there are objections. Will wait some days for feedback.

-- KennethLavrsen - 25 Jul 2006

Thanks for bringing this up, Kenneth, I agree the behaviour should be altered to not expanding the variables.

Reported the locking issue from above as Bugs:Item2684.

-- SteffenPoulsen - 25 Jul 2006

Kevin, thanks for your advice re: installation. Though, I think there may be a problem with contents of the .tgz file. After I switched over to the .zip, everything, began to work correctly.

PS -- thanks for the advice re: the translations of variables, noticed that problem within the first 30 seconds and it's great to have a fix !

-- KeithHelfrich - 25 Jul 2006

The zip file seems to be an old version. And the tgz file is the version updated for TWiki4.

So you have found TWO severe problems.

  • Why doesn't the TWiki4 version run on Cairo?
  • Why did Will upload an old zip? Is there a bug in the build script?

If the new EditTablePlugin is no longer compatible with Cairo, we should make sure there is still a Cairo version available for download.

I have checked and the zip file is the same EditTablePlugin version that I had running in Cairo.

And the tgz is the current TWiki4 EditTablePlugin

What I will do now is to upload an EditTablePlugin_cairo.zip and upload a TWiki4 version of the zip so at least things are correct.

I will not try and test and fix the TWiki4 version on Cairo because it has been totally rewritten and split in more files.

-- KennethLavrsen - 26 Jul 2006

This is an essential Plugin. It needs to be fixed so that it runs on Cairo and Dakar.

-- PeterThoeny - 26 Jul 2006

Agreed, it would be best to make do with just one version of this plugin. I will try to get back to the issue at some point later.

Bugs:Item2684 fixed, new version uploaded.

-- SteffenPoulsen - 29 Jul 2006

I looked at the the TWiki4 version installed in Cairo.

It it not going to be easy to make a single version of this plugin.

For anyone wanting to upgrade the plugin on Cairo they will have to install a new version of JSCalendarContrib. There is also a new dependency of the Assert.pm file in lib/TWiki.

I tried to comment out anything related to Assert and JSCalendar. Then the plugin runs but when you edit a table it inserts "." after each character at each save. So something more basic would need to be updated. And this where I personally say STOP AND THINK.

Let us look at the business case to do this.

Why would a Cairo admin download and install EditTablePlugin?

  • Answer: In reality he has no reason to. The EditTablePlugin was distributed with Cairo. In Cairo it was a default plugin part of the TWiki download. Just like it still is in TWiki4. The only reason why he downloads an update is because he gets the wrong impression that he gains something from it. In reality he gets compatibility trouble with JSCalendar and not a single enhancement or bugfix. Even the last bugfix that Steffen did is related to TWiki4.

In my oppinion we are not doing anyone a favour by trying to make a Cairo+TWiki4 version of this plugin.

Try and put imaginary values on this business case. Let us use the currency cyber-bananas.

The business case of making a Cairo/TWiki4 compatible version of EditTablePlugin

Pro/Con Value Gained Value Lost Comment
Admin has ONE download file to choose from 1000 0 Value could be less we better keep a clearly marked Cairo version available and a clear note which version number is the last Cairo version
Admin's effort to do the upgrade 0 1000 Needs to also update JSCalendarContrib
Features that Cairo users gain from common Plugin version 0 5000 No new features. Need to fix topics after JSCalendar files have physically moved to different location in pub tree
Features that TWiki4 users gain from common Plugin version 0 3000 The requirement of Cairo compatibility has in practical shown that developers avoid the plugins with this requirement. There are very few enhancements released on old essential plugins.
Developers only maintain one version 0 5000 There is in reality no development for Cairo
Developing for Cairo requires that you have a Cairo installation running and lots of test topics that use the plugin
Quality of plugin 0 2000 For TWiki4 the quality now depends on code that meant for Cairo only. For Cairo the new versions of the plugin are very poorly tested on Cairo. Risk of new escaping bugs into Cairo is huge.
Speed of plugin 0 1000 More code to compile in Dakar and in Cairo. Both looses speed. Maybe be a marginal loss but many marginal losses add up to a big loss. That is how TWiki got slow

Another plugin with much less effort to maintain compatibility and where added features or more important bugfixes could benefit Cairo users could create a business case that favours a compatible single version.

But for this plugin it makes very little sense.

This issue we had recently was that a core developer has overwritten the Cairo version with a Dakar version without leaving behind a working Cairo version for download and this is totally unacceptable. As a minimum the last stable Cairo version must be clearly and well marked available for download. And also marked so a Cairo admin that visits the plugin topic can clearly identify that indeed he does have the latest Cairo version.

-- KennethLavrsen 20 Jul 2006

Hi Kenneth. I totally agree. I am running CairoRelease and did not understand that the plugin was provided by default. I only installed it because I wanted to add the functionality. (Though, since I arrived at Cairo by upgrading from BeijingRelease -- was the plugin still provided by default ?)

Anyway, no matter really, because I was lucky enough to find a Cairo version of the .ZIP and now everything is working beautifully. My users are editing tables!

It seems to me that this is a very complicated plugin and that maintaining a single version compatible with both Cairo and DakarRelease would be a nightmare. I've already suggested in EncouragingUpgrading that while I haven't upgraded to Dakar yet myself, I believe that most twiki admins should upgrade .. and that if a plugin reaches the "leave Cairo behind" phase of it's development then so be it! At least a copy of the most recent stable Cairo version should be available for download and that is sufficient. At least, those are my 2cents for whatever they are worth smile Thanks for your help and for the fantastic plugin!

-- KeithHelfrich - 31 Jul 2006

I have tested the proposed change of sub commonTagsHandler { to sub beforeCommonTagsHandler {

Saving the table works great. I did not find any issues. But when you include a topic with EDITABLE in another topic the includes table is not rendered correctly. You see the %EDITTABLE tag and no edit button.

So this primitive code change does not fly. It takes more than that. Probably the code that runs for rendering should be in commonTagsHandler and the code that runs when you hit save needs to be run BEFORE the TWikiVariables inside the table gets interpreted.

Back to the good old "drawing board". Coder needed.

-- KennethLavrsen - 02 Aug 2006

It appears that the "Argument isn't numeric" problem is still around:

viewauth: Argument "22 color" isn't numeric in numeric lt (<) at /var/www/html/twiki/lib/TWiki/Plugins/EditTablePlugin/Core.pm line 556.

This is on Dakar!

-- DougClaar - 08 Aug 2006

Just a minor note:

The file data/TWiki/EditTablePlugin.txt,v is missing in *.zip and *.tgz files.

-- DaliborSvoboda - 15 Aug 2006

Yes, that is a limitation/feature of the build tool. I prefer to have the history files packaged in the distribution.

-- PeterThoeny - 16 Aug 2006

Small doc fix: The documentation still refers to Codev/JavaScriptDatePickerForForm while it should refer to Plugins/JSCalendarContrib

Small question: it seems that %EDITTABLE% doesn't work, but %EDITTABLE{}% does work. I haven't seen this in any other plugin (normally leaving the parentheses away means choosing default values) It this a bug or a feature?

-- JosMaccabiani - 29 Aug 2006

Bug or feature, that is the question. smile %EDITTABLE% can be added easily.

-- PeterThoeny - 29 Aug 2006

Is there any news concerning Bugs:Item2690 ? This is the problem we have experienced with sorting a table by clicking on the a table heading.

-- PeterJones - 31 Aug 2006

Nobody seem to have looked at this bug at this time.

-- PeterThoeny - 19 Sep 2006

After the proposal EditTablerowPluginAsDefaultPlugin has been pulled back as not feasible we need to look at this very essential plugin and the many good ignored contributions below.

My wish list (which seems to match the wishes of many on this topic) for EditTablePlugin is

  1. Ability to edit one row at a time. Maybe a discrete dot or arrow or thick line on the side of the table to pick a row for selection. Per default this would be disabled and have to be enabled by a new parameter in EDITTABLE tag to maintain compatibility.
  2. Not loose the ability to edit all rows at the same time. If you need to quickly update many cells a user interface that requires click, edit, submit for every row is a major pain.
  3. Need ability to add and delete arbitrary row. This could be simply by clicking the small arrow/dot/bar to get to single row edit mode, and then you can either add new row below or above, or delete current.
  4. Need the TablePlugin to not interpret TWikiVariables to static text when you edit and save. This is a major limitation to the use of the current EditTablePlugin.
  5. Need the formatting of the editing of single rows to be defined by the EDITTABLE options and not require a form topic to define the format. I would be satisfied with the current set of definitions.

-- KennethLavrsen - 05 Oct 2006

Ken, please explain the point (4) in your wishlist. Evaluating text in the table definition appears to me to be a feature, as it allows you to, for example, put timestamps into the table. EditTablePlugin defines the standard escapes to prevent expansion. It would be good to learn what your concerns are here.

On the other points.... as you know (1) and (3) are supported by EditTablerowPlugin. Combining both plugins into a single one would require some use cases to be described. It is doable, but leverages quite different underlying aspects, so basically this plugin would be doubly the size. And then there is the cell-specific setting which sticks out like a sore thumb....

On your point (5), I can only say that more often than not I had to go back and replace an inline definition with a include or form-based definition to allow a systematic change to many tables. I can see the use case, but my experience proves it to be a seductive one that more often than not is misguided....

-- ThomasWeigert - 11 Oct 2006

Submitted the following as Bugs:Item2975....

I have recently had problems with EditTablePlugin and traced it to TWiki::Plugins::EditTablePlugin::Core::parseFormat , line 210:

     $theFormat = TWiki::Func::expandCommonVariables( $theFormat, $theTopic, $theWeb );
Under certain circumstances, after this $theFormat has an extra newline appended, which results in that the table does not correctly reflect the value stored in the topic when we have select, checkbox, or similar restricted types, for the last entry in a row.

We either need to figure out why the extra newline is added, or remove it in parseFormat .

-- ThomasWeigert - 11 Oct 2006

FYI i changed the plugin in SVN to pick up the default date format from JSCalendarContrib. it was confusing users. i did not re-release the plugin (it doesn't list JSCalendarContrib in DEPENDENCIES - is this deliberate?)

-- CrawfordCurrie - 12 Oct 2006

Thomas, an example of Ken's point 4 is the ability to put something like %ATTACHURL% in a table and not have it expanded by EditTablePlugin, yet have it correctly expanded when rendering the page. Currently the %ATTACHURL% is expanded into the absolute URL which is stored as part of the page content. I'd like %ATTACHURL% to remain as %ATTACHURL%. As far as I can tell there's no way of escaping it without also turning it into static text which isn't recognized as a TWikiVariable.

-- DiabJerius - 15 Oct 2006

The EditTablePlugin manual is clear: you put %ATTACHURL% into the text, it is expanded right away. You put $percntATTACHURL% there (or escape the tag in some other way), it is not, but expanded when the page is rendered.

I don't understand what the problem is....

-- ThomasWeigert - 27 Oct 2006

My personal problem with the code as it stands currently is that it has broken old code that used to work.

In previous versions of TWiki, I used to have an editable table allowing people to populate columns with numbers, and then have a SpreadSheetPlugin calculation in a left column of the form: \%CALC{ \"\$SUM(\$RIGHT())\" }\% to calculate the total---incidentally, I've also had to escape that code here to prevent evaluation. (I've used this to build a web-based scoreboard for a sailing group that I race with, FWIW.) This code is now overwritten with the result of that calculation every time someone uses the edit table button to update the scores. (It used to not be overwritten, and perform the calculation at page render time.) To me, that is a bug introduced in the new codebase. I'm happy to work around that bug, but the documentation needs to be clearer on how to accomplish that!

I've tried various and sundry permutations of the escaping documented on this page, and nothing seems to work.

I need two different styles of SpreadSheetPlugin commands at different rows in the same column. This implies that I need to have the ability to protect my code from expansion on a cell-wise basis (as opposed to a column-wise basis).

How do I accomplish that within the current codebase? (A working example would be most appreciated!)

-- FrankHorowitz - 12 Nov 2006

Hmm, I am not aware of a change in the behaviour. If this is the case it should be fixed. In any case, if you declare a column as a type label it should not expand the CALC.

-- PeterThoeny - 12 Nov 2006

Thank you Peter! That gave me the clue that I needed to solve my problem! All I had to do was declare that column to be of type label and my code was protected from being clobbered by a table edit.

(Perhaps it's worth considering whether or not the current codebase needs to be "corrected". It may well be that I was relying upon a bug in the old codebase in that it didn't expand variables in columns of type text and now it does.)

I'm a happy camper!

-- FrankHorowitz - 12 Nov 2006

Frank, your scoreboard sounds very much like the AccountRegisterApp that I just asked for in TWikiApplications. Knowing nothing about the SpreadSheetPlugin, myself, could I convince you to whip up a HOW-TO ?

-- KeithHelfrich - 25 Nov 2006

Even when using the label declaration for my column, there's still a problem with the AccountLedgerApp. Any thoughts on why ? Interesting that it works correctly at home on CairoRelease ..

-- KeithHelfrich - 12 Dec 2006

I'm having a very annoying problem with that plug-in. See my comment on EditTableReplacesHeaders. Could it be that it works just fine as long as you only have one person editing a table at a time?

-- StephaneLenclud - 17 Dec 2006

I've worked around it, and CairoRelease is old news. But I thought I'd report that EditTablePluginBreaksVerbatimOnCairo

-- KeithHelfrich - 17 Dec 2006

Follow up to my 05 Oct 2006 wishlist and Thomas question of 11 Oct 2006.

It is not correct that you can use $percnt to escape variables from being expanded. I am talking about the normal user who wishes to write some text in a cell and use a TWiki variable. The minute he saves it it becomes a static text. And that is bad. If the user types TWiki Variables in normal edit mode then they should not be expanded.

Time stamps etc is another deal but they are defined in the EDITTABLE format as initial values and they should be expanded when you click the add new row like they are today and here you can use the $percnt escape.

But then a user writes %RED%Delayed%ENDCOLOR% is should not be expanded to static <font color="#ff0000">Delayed</font>

-- KennethLavrsen - 07 Jan 2007

Quite often we have found that we have created topics with the EditTablePlugin that only contain the table being edited. Our users were complaining about the page 'jumping up' to the top of the table, so I looked at the plugin code and added a parameter called "jumpanchor" which defaults to "on" but can be switched off to make the plugin view the whole topic without the anchor.

I've attached my version of the "Core.pm" file in case anyone else finds this useful.

Feel free to include this change or not.

Cheers.

-- DuncanKinnear - 21 Jan 2007

I've added the following WBNIF to the #Wishlist above.

  • Some tables are very large and it is often desirable to have an edit button at both the top and bottom of the table. Thus a parameter to specify vposition="top, bottom, or both" would be very helpful. -- KeithHelfrich - 22 Jan 2007

-- KeithHelfrich - 22 Jan 2007

There has been some new stuff added to the #Wishlist above. And also, a question :

Is it possible use a %CALC{$RAND(1000000)}% command as part of a "label" or "select" in a cell, but only have the randomness happen for new rows ?

In other words, each new row would be inserted with a random value, but thereafter, since the cell is a label, the random value would remain persistent and not fluctuate for the historical cells each time the table is edited..

-- KeithHelfrich - 02 Feb 2007

One another point to variable expanding issue. I want to create a drop-down box with predefined list of options which are stored in TWiki variable. Here is how I'd like it to work:

   * Set OPTIONS = first, second, third
In editable table I want a multiple use of cell definition:
   %EDITCELL{select, 1, %OPTIONS%}%
The idea is, if I want to change a list of OPTIONS I do it in one place only (variable definition) and not in each cell in table the list is in use. Think e.g. that i want to have list of TWiki users in drop-down list which changes very often.

The above does not work as variable gets expanded after first edit/save on table. Is there any way to get such a behavior with EditTablePlugin? But one thing more not to be misunderstand. I want to be able to predefine the dropdown list for such tables in any possible way . The TML showed above is an example only to better describe my problem.

BTW expandable variables are not very intuitive and I totally agree with KennethLavrsen and his 07 Jan 2007 comments in this case.

-- JacekZapotoczny - 16 Feb 2007

See also the conversation in ControlOverVariableExpansion

-- KeithHelfrich - 17 Feb 2007

To solve the expanded variables issue with EDITCELL I have posted an experimental patch. This patch adds a parameter called cells to EDITTABLE. The syntax of the cells parameter is exactly the same as the format parameter except it has a spreadsheet like prefix e.g. cells="|R2:C2, select,1,val1,val2||R3:C2, text, 5|" or cells="|R2:C2..R4:C2, select,1,val1,val2|R3:C2..R9:C2, text, 5|"

Expanded variables are not a problem as the arguments for this parameter are not part of the table contents exactly like the format parameter.

It also has the advantage that these cell settings are compatible with the include parameter unlike editcell settings.

-- PatrickDiamond - 21 Feb 2007

I like this approach, it removes the unwieldy cell difinition from the actual cell! One slight disadvantage is that you can't easily refactor the table (e.g. move cells around.)

-- PeterThoeny - 22 Feb 2007

A couple of bugs:

  • Double newlines in the input text get eaten: they get translated into one single br.
  • A backslash character will break the table as soon as a EDITTABLE tag is above the table.

-- ArthurClemens - 04 Mar 2007

I have fixed the double newlines bug, together with the changes for the javascript interface, see Bugs:Item3766.

The backslash char problem is still there.

-- ArthurClemens - 15 Mar 2007

Does no one else have the following problem with this plugin? Support.EditTableReplacesHeaders It's a severe problem making the plugin nearly useless - how do you cope with the problem - don't you use mod_perl with your TWiki installation?

-- AlexRaabe - 24 Apr 2007

A newly initialized table placed at the top of a topic will calculate cell values from the next lower table if there are multiple tables on a page. The table initializes correctly if it is placed at the bottom of the topic page. Work around #1 - Initialize table at bottom of page and then cut/paste to top by using topic editor. Work around #2 - Initialize table, Save Table Edit table, delete last row, save, edit, should show header only, Add a row and it should work from here

-- LorenEvey - 29 Apr 2007

I created a page in support describing this, and now realise this is probably the place to post.

The following link shows a table on twiki.org sorting a date column, but clearly getting it wrong for both month and year:

https://twiki.org/cgi-bin/view/Support/BugreportEditTablePluginSortIssue?sortcol=3;table=1;up=0#sorted_table

-- CarlGherardi - 23 May 2007

Hi. I have seen rare but very strange behaviour with EditTablePlugin. The situation occurs when two topics in different webs just happen to have the same heading for one of the columns in an edittable. Very rarely (twice in three months) the contents of the column from one table in one web1.topic1 is written to the table in web2.column2 ! This has happened with a number of different web.topics.

I am running 4.0.5 on RedHat 7.2, apache 1.3. I am running speedyCGI on view/viewauth, but not save.

Can anyone advise what could cause this ? Thanks, Steve.

-- SteveJonesST - 07 Jun 2007

We ran into an unfortunately contention issue today with a very popular editable table.

One of my co-workers is doing an internal one-day conference and set up a TWiki page to take "registration" information. Most of the team hit it during the same window.

We had people lose data. History shows the row was there, then not there when the next person saved. Appparently a lot of people were doing near-simultaneoous edits.

I would have hoped the merge functionality would have handled this. Perhaps the edits were just too close in time?

I thought I'd mention this. Has anyone else seen a similar problem? We've got (I think) TWiki 4.05.

-- VickiBrown - 14 Jun 2007

Regarding variable expansion KennethLavrsen wrote
Need the TablePlugin to not interpret TWikiVariables to static text when you edit and save. This is a major limitation to the use of the current EditTablePlugin.

ThomasWeigert wrote
Evaluating text in the table definition appears to me to be a feature, as it allows you to, for example, put timestamps into the table. EditTablePlugin defines the standard escapes to prevent expansion. It would be good to learn what your concerns are here.

KennethLavrsen wrote
It is not correct that you can use $percnt to escape variables from being expanded. (he's correct; this doesn't work in table cell content - vb) ... [if] a user writes %RED%Delayed%ENDCOLOR% it should not be expanded to static <font color="#ff0000">Delayed</font>

Automatic variable expansion is a very serious failing for us too. Personally, I don't so much mind if %RED% is converted to the associated <font tage. However, when an %INCLUDE% is expanded, it loses its value! We want to import data dynamically from another page, not noe time only (and after that it's static .:-(

It's not a feature for a variable to be expanded (replaced) by a constant string . Variables should remain variable. They should only be expanded when the page is rendered; never in the underlying source.

-- VickiBrown - 22 Jun 2007

I've reformatted a #Wishlist item above to make it more clear .. the ability to reduce the number of clicks needed for inserting a new row. Wouldn't that be super ! wink

-- KeithHelfrich - 08 Jul 2007

The change log implies that JSCalendarContrib is required, but it isn't listed as a dependency. If it is required, what version of JSCalendarContrib is required?

-- EricHanson - 03 Aug 2007

is there a convenient way to "suck in" the values of a select field from somewhere else? TWiki forms do this with tablles in pages.

Variables don't seem to expand in the format section; otherwise, I'd put my menu list into a variable

-- VickiBrown - 14 Sep 2007

A small patch to avoid getting annoying error messages in the Apache log if the size of a textarea field isn't given.

-- MartinKaufmann - 27 Sep 2007

Funny, there is a configuration setting that allows to change the label of the [ Edit ] button but there seems no possibility to change the other button labels (Save, Quiet save, Add row or Cancel). Shouldn't they be language dependent anyway? This is a core plugin, so if I change the language of the interface, the labels of the buttons of this plugin should change too, shouldn't they?

And why can't the settings for this plugin be defined on a web basis. Thought this is standard for all plugins/variables. Wanted to turn off the new (ugly) JavaScript resorting/delete feature for a specific web.

Had some uncomfortable user experiences the last days while testing the latest beta (beta2) on the virtual environment of the TWikiVMDebianStable with multi-language support turned on (need the german interface), so please excuse my harsh words. wink

-- FranzJosefGigler - 10 Oct 2007

All sensible suggestions. Please provide separate bug reports on https://develop.twiki.org/. I would also like to hear any suggestions improving the resorting interface.

-- ArthurClemens - 18 Oct 2007

While I was working on the plugin I have done these fixes:

It is already possible to switch off the javascript interface per web. In the web's WebPreferences, write:

   * Set EDITTABLEPLUGIN_JAVASCRIPTINTERFACE = 0

I have also made the javascript buttons less obtrusive.

-- ArthurClemens - 18 Oct 2007

To get rid of the Edit button on print-outs, I added the following lines to the end of twiki/pub/TWiki/PatternSkin/print.css (I'm using PatternSkin):

        .editTableEditImageButton {
                display:none;
        }
Could this also be achieved by altering the viewprint template?

-- MartinKaufmann - 13 Nov 2007

Thanks Martin. This is tracked now in Bugs:Item4995.

-- PeterThoeny - 20 Nov 2007

Is there a reason why the initsort parameter from %TABLE% is not supported in EditTablePlugin (or did I miss something)? It would be especially handy for tables which grow organically.

-- MartinKaufmann - 14 Dec 2007

It is supported, but indirectly. Just add the line %TABLE{initsort="1"}%.

-- ArthurClemens - 14 Dec 2007

Thanks! That does the trick. Is there no problem having the two statements (%TABLE% and %EDITTABLE%) together for one table? I guess this solution would also work for EditRowPlugin.

-- MartinKaufmann - 14 Dec 2007

The TABLE attributes only work for the view mode of the edit table. In fact, sorting should be disabled for edit mode but I couldn't find a quick way to do that.

-- ArthurClemens - 14 Dec 2007

Hm, is it possible to create an URL that views a topic in edittable mode, thus making it possible to start editing e.g. the first table on that topic via a link?

-- FranzJosefGigler - 16 Dec 2007

Yes: add ?etedit=on;ettablenr=1 to the url (before any # sign) in the url string.

-- ArthurClemens - 16 Dec 2007

Thanks Arthur, this helped me documenting TWikibug:Item5147.

-- FranzJosefGigler - 18 Dec 2007

Is it possible to place the edit button at the top of the table. With large tables it would be beneficial.

-- JeffHladek - 08 Jan 2008

I have just upgraded our version of the EditTablePlugin by untarring the tgz file over the top of the installed version we already had. We have the new buttons under the tables, but when we go to click on the button, we get an error screen with the error:

Can't locate TWikipath in @INC etc.

We're running version 4.1.1 of TWiki.

Any ideas?

-- DuncanKinnear - 08 Jan 2008

What does your server error log say?

-- ArthurClemens - 08 Jan 2008

I just looked at that and it gives me a bit more of a clue.

The error there is: Can't locate TWiki/Contrib/BehaviourContrib.pm in @INC

We have the BehaviourContrib installed (version 1.0 which came with TWiki 4.1), but there is no BehaviourContrib.pm file with that version.

Is there a newer version of the Contrib that has a .pm file?

-- DuncanKinnear - 08 Jan 2008

Hmmm. It appears that the pm file was added to the BehaviourContrib distribution on 10 Oct 2007 by CrawfordCurrie.

Is the current version of the EditTablePlugin now dependent on that version of the BehaviourContrib?

If so, then perhaps this should be mentioned in the dependencies.

-- DuncanKinnear - 08 Jan 2008

Arthur,

I need to know if I just need to upgrade BehaviourContrib to fix this problem. Currently the EditTablePlugin is not working here and I have users who are starting to complain. I don't really want to re-install the previous version.

If I upgrade BehaviourContrib what are the knock-on effects?

-- DuncanKinnear - 09 Jan 2008

I don't think there will be any.

-- ArthurClemens - 09 Jan 2008

I can report the same problem. We're running TWiki 4.1.2 at Westermo R&D. After upgrading to the latest BehaviourContrib EditTable no longer barfs on me. I have seen no side effects either.

-- JoachimNilsson - 16 Jan 2008

I may have a simple improvement for the ever-returning variable expansion problem. In the inputElement function, the entries for 'radio', 'checkbox' and 'select', the unexpanded $val is used both for the posted value and for the rendered form element. The attached Core.pm uses the expanded $valExpanded for the rendered form elements instead.

Unfortunately, I'm not administering any working TWiki so I can't really test it.

-- ArnoutVandecappelle - 24 Jan 2008

Added to the wishlist above...

Something that often annoys me about EDITTBLE is that it doesn't respect multi-column (colspan) table cells.

For example, today I created a table

Project Dev Test Staging Production

Yes/No Date Yes/No Date Yes/No Date Yes/No Date
                 

I want the "Dev", "Test", Staging", "Production" cells to span two columns so that they sit above the appropriate "Yes/No" and "Date" columns. And this works, until I add EDITTABBLE at the top.

EDITTALE asumes that the || following Dev, etc, are simply "empty cells" of whatever type fits in that location in the table. So, I have to go back and fill them (I use *<hr>* as a reasonable "nothing" value. And then my colspans are broken

Ugh.

-- VickiBrown - 07 Feb 2008

When using checkboxes in an EDITTABLE, there are always spaces around the commas in the resulting table (e.g. Option1 , Option2) which doesn't look nice (to me at least). I attached a patch to remove the first space. The patch only works for new tables, it won't affect old ones.

-- MartinKaufmann - 15 Feb 2008

Im trying to setup a table where every row will have a link to a folder on our network. The problem Im having is when I put a HREF command in a text field it shows as "<AHREF=>". When I enter it into the table when doing an edit it works fine. Any ideas?

-- JeffHladek - 15 Feb 2008

I have installed the latest versions of both EditTablePlugin and BehaviourContrib. But I don't have the new JS up/down arrows or the delete box. What am I still missing? (It's TWiki 4.1.2)

-- VickiBrown - 03 Mar 2008

To JeffHladek - re: button at the top of the table -- see Support/EditTableButtonTopAndBottom

-- VickiBrown - 03 Mar 2008

I added the following to pub/TWiki/EditTablePlugin/edittable.js

var twiki;
if (!twiki) twiki = {};
twiki.getMetaTag = function(inKey) {
    if (twiki.metaTags == null || twiki.metaTags.length == 0) {
        var head = document.getElementsByTagName("META");
        head = head[0].parentNode.childNodes;
        twiki.metaTags = new Array();
        for (var i = 0; i < head.length; i++) {
            if (head[i].tagName != null &&
                head[i].tagName.toUpperCase() == 'META') {
                twiki.metaTags[head[i].name] = head[i].content;
            }
        }
    }
    return twiki.metaTags[inKey];
};

That's from pub/TWiki/TWikiJavascript/twikilib.js of TWiki-4.2.

-- MichaelDaum - 12 Mar 2008

Release 4.8 fixes a number of problems:

  • Fixes a bug with variable expansion and SpreadSheetPlugin
  • To prevent variable expansion it is no longer required to use $percnt, this is now done automatically
  • Sorting is disabled when editing to prevent messing up the order
  • The Javascript interface is now aware of TablePlugin parameters headerrows and footerrows
  • I have included Michael Daum's javascript patch
  • I have not included Martin Kaufmann's patch because it breaks smilies (and possibly other variables)

-- ArthurClemens - 19 Mar 2008

EditTablePlugin depends on BehaviourContrib. It does not list it in its DEPENDENCIES file, same for JSCalendarContrib. But why does it need it at all? I looked at the code and can't find the spot where it calls BehaviourContrib. It seems safe to remove

    require TWiki::Contrib::BehaviourContrib;
    TWiki::Contrib::BehaviourContrib::addHEAD();
from the plugin's code.

-- MichaelDaum - 14 Apr 2008

You are right. It is a remnant from older code.

-- ArthurClemens - 14 Apr 2008

k

-- MichaelDaum - 14 Apr 2008

When I INCLUDFE my table from another page, it works erfectly. However, when a user licks Edit, s/he ends up editing the "real" page, not the page the table is INCLUDEd into.

Is there a recommended way to take the user back to the original age when the editable table is saved?

-- VickiBrown - 14 Apr 2008

Not yet.

-- ArthurClemens - 14 Apr 2008

I note that EditTablePlugin very much needs to support headerrows and footerrows params similar to TablePlugin. The JavaScript interface understands these now (so they aren't something I can move around) but EditTable still tries to use them as individual editable cells. frown

There are times (e.g. if I have a header that spans several columns) that I do NOT want EditTable treat any portion of the header row as editable. I need a way to tell it not to.

%TABLE{headerrows="3"}%
%EDITTABLE{format="|text,30| select,1,,done %<nop>Y% | text,6 | text,6 | text,6 | text,6 | text,6 |  |"}%
|  *%RED% ACTIVE CANDIDATES %ENDCOLOR%*  ||||||||||
| *Name* |  *== Status ==*  ||||| *Active?* | *Source* | *Screener* |*Screener Notes*|
|^| Resume | Screen | Int | Offer | Hired |^|^|^|^|
| Bob Smith | done %Y% | done <img src="http://twiki.corp.yahoo.com/pub/TWiki/TWikiDocGraphics/choice-yes.gif" border="0" alt="DONE" width="16" height="16" /> | done <img src="%PUBURL%/TWiki/TWikiDocGraphics/choice-yes.gif" border="0" alt="DONE" width="16" height="16" /> |  |  | Yes | recruiter | Team | Thumbs up; going to SM for round 2 |

ACTIVE CANDIDATES
Name == Status == Active? Source Screener Screener Notes
Resume Screen Int Offer Hired
Bob Smith done DONE done DONE done DONE     Yes recruiter Team Thumbs up; going to SM for round 2

-- VickiBrown - 17 Apr 2008

Upgrade to the latest EditTablePlugin and TablePlugin. Then add headerrows and footerrows parameter to the TABLE tag:

%TABLE{headerrows="2"}%
%EDITTABLE{...}%

The reason why the rows parameters are not copied to EditTablePlugin is because these parameters change the drawing order of the rows. And EditTablePlugin itself does not draw the table, that is delegated to TablePlugin.

This is also documented by the way.

-- ArthurClemens - 17 Apr 2008

Since upgrading from the 01-Sep-2004 release to 4.2.0, we are seeing a problem not dissimilar to Adam Ellis' in June 2006.

We have LDAP authentication working for editing and some viewing. I have a page with ALLOWTOPICVIEW and ALLOWTOPICCHANGE set. It correctly forces authentication before viewing (so viewauth appears to work - which I thought was the main precondition for EditTablePlugin to work) and allows a smaller group to edit the page itself.

However, click the EDIT button at the bottom of the table and the Access check fails and 'Action "change": denied' is displayed.

I can login as the internal admin and then I can use the EditTablePlugin.

Where should I be looking?

-- IanCollier - 23 Apr 2008

I believe that I have found a serious potential dataloss bug in the latest version of EditTablePlugin.

Create a situation like this:

%EDITTABLE{}%

| col 1 | col 2 | col 3 |
| dog | fish | cow |

In the "previous" version of EditTable, this would result in a button (for an empty ediitable table) shown above an uneditable table with two rows.

In the new version of EditTable, this results in the "empty" button. The other table is not presented. Worse, if you click the button and add a row, the "uneditable" table is removed from the page source.

This reproduces on a personal TWiki, v. 4.12 with the newest EditTable update installed. I cannot test on twiki.org.

  • screenshots:
    vb_screenshot.jpg

-- VickiBrown - 18 Jul 2008

More information. This does NOT reproduce in EditTablePlugin (4.7.10, $Rev: 16239 (25 Jan 2008) but does reproduce with 4.8.2, $Rev: 16617 (07 Apr 2008) $). Both TWikis are v. 4.1.2

TWiki bug filed TWikibug:Item5794.

Found a fix.
-- TWiki:Main/ArthurClemens - 19 Jul 2008

Yippee!

-- VickiBrown - 18/21 Jul 2008

This is weird... "Add Row" in EditTable 4.8.2 breaks the table headers in one of my TWikis.

%EDITTABLE{headerrows="2"}%
%TABLE{headerrows="2" sort="off"}%
| *Column 1* | *Column 2* | *Column 3* |
| *Foo* | *Baz* | *Flip* |
| apple | banana | orange |

becomes

%EDITTABLE{headerrows="2"}%
%TABLE{headerrows="2" sort="off"}%
| </strong>Column 1* | </strong>Column 2* | </strong>Columnn 3* |
| </strong>Foo* | </strong>Baz* | </strong>Flip* |
| apple | banana | orange |
| | | |

this is only reproducible on a 4.05 TWiki running EditTablePlugin 4.8.2. It only happens when there are two header rows. (My 4.12 TWiki doesn't reproduce this) Any suggestions?

-- VickiBrown - 21 Jul 2008

Which version of TablePlugin are you using?

-- ArthurClemens - 23 Jul 2008

Arthur - That was the problem. I had the admins install the latest TablePlugin on our test server and the EditTable row-breaking problem is gone. (Now to onvince the admins to update TablePlugin on the production server!)

-- VickiBrown - 23 Jul 2008

New EditTable update posted at EditTablePlugin to address TWikibug:Item5794. Thank you Arthur!

-- VickiBrown - 29 Jul 2008

We have people (don't ask me why) who try to do things like this:

%EDITTABLE{}%
<font size="2">
| *A* | *B*| *C* |
| apple | banana | cherry |
</font>

The newest version of EDITTABLE sees this as an empty EDITTABLE request followed by a static table wrapped in font tags.

Apparently, previous versions of EDITTABLE ignored the font tags and edited the A B C table.

Personally, I think shoving extra stuff between EDITTABLE and the table rows is incorrect syntax. But for backward compatibility I could argue the other way.

Comments? What do you think EDITTABLE should do in the example given above?

-- VickiBrown - 31 Jul 2008

IMHO it should strike the person with an electric shock. wink

-- FranzJosefGigler - 31 Jul 2008

I also use this kind of font tags when I have a large table I want with smaller fonts.

How else can you do it? Unless you want to make CSS files for the topic.

But I just put the font tag before the edit table tag.

-- KennethLavrsen - 31 Jul 2008

Best practice would be to give the table an id (TablePlugin id attribute) and add some inline css to set colors, size etcetera.

-- ArthurClemens - 01 Aug 2008

Kenneth - yes, put the font tag above the edit table tag. That would be what II would do. But should we support putting it after the EDITTABLE? Currently, we do not

-- VickiBrown - 01 Aug 2008

We have updated both EditTable and Table Plugin and EditTable is (still) not respecting headerrows value in Table.

-- VickiBrown - 01 Aug 2008

Added to WishList:

* enhancement to include parameter to not require _the first %EDITTABLE% in the named topic." If I have more than one unique editable tables on a page and I want them all to get their parameters from a shared location, I currently need one page EDITTABLE definition. Multiple pages increases risk of confusion; I'd like to be able to say something like include="TopicName" section="Section" (ala sections in %INCLUDE%).

-- VickiBrown - 05 Aug 2008

Wish: finally merge EditTablePlugin and EditRowPlugin featurewise and replace the actual EditTablePlugin with an enhanced EditRowPlugin which seems more thought out architecturalwise.

-- FranzJosefGigler - 05 Aug 2008

Ran into a new interesting bug:

EditTablePlugin is very nice in that you can combine it with other plugins that generate tables to then edit the resultant table structure and have the edited result saved into the topic. In other words, the table to be edited may be the result of another TWiki tag, rather than have been loaded from the topic. Examples of this are when the table can be optionally retrieved from somewhere other than the saved topic (e.g., a web site, a data base), but we then want to be able to edit the table and save into the topic. This works very well, almost. However, there is one gotcha.

In order to explain this better, let me review the algorithm this plugin uses when saving:

  1. if it is determined that a save button was pressed, call processText again in saveMode
  2. now load the saved text for the topic
  3. merge the text from the query with the saved text in the topic for the edited table:
    1. for each row in the saved text, replace its fields with fields passed in from the query
    2. if there are added rows in the query, add these to the table
  4. save the topic

The problem occurs if the table in the query is different from the stored table, but there are fields that were formatted as labels. These fields will not be passed to the plugin for update, and consequentially will not be updated in the text. The stored values will be chosen instead.

-- ThomasWeigert - 10 Aug 2008

I am confused. Is this a bug or user error?

Global preference JAVASCRIPTINTERFACE is set to 0.

If I Set

   EDITTABLEPLUGIN_JAVASCRIPTINTERFACE = 1
in a topic, I do not et the expected JavaScript interface. However, using
javascriptinterface = "on"
in the EDITTABLE parameters does work as expected.

-- VickiBrown - 11 Aug 2008

I just chatted on the support page about EDITTABLE not supporting the sort="off" attribute. If this is correct, would it be possible to add this as a feature request?

-- AndyWozniak - 19 Aug 2008

Table functions are supported by TablePlugin. Add a line %TABLE{sort="off"}% above the EDITTABLE line.

-- ArthurClemens - 19 Aug 2008

Does this work on 4.2.2? I can edit a table, but when I save it, nothing happens. The resulting page includes the table as if it hasn't been edited. Enabled DEBUG, everything seems normal:

| 2008-08-28 - 11:22 | - TWiki::Plugins::EditTablePlugin::initPlugin( Identity/Data/Foundations/InformationSystem.Requisitos ) is OK
| 2008-08-28 - 11:22 | - EditTablePlugin::commonTagsHandler( Identity/Data/Foundations/InformationSystem.Requisitos )
| 2008-08-28 - 11:22 | - EditTablePlugin::doEnableEdit( Identity/Data/Foundations/InformationSystem, Requisitos )
| 2008-08-28 - 11:22 | - TWiki::Plugins::EditTablePlugin::initPlugin( Identity/Data/Foundations/InformationSystem.Requisitos ) is OK
| 2008-08-28 - 11:22 | - EditTablePlugin::commonTagsHandler( Identity/Data/Foundations/InformationSystem.Requisitos )
| 2008-08-28 - 11:22 | - EditTablePlugin::doEnableEdit( Identity/Data/Foundations/InformationSystem, Requisitos )
| 2008-08-28 - 11:22 | - TWiki::Plugins::EditTablePlugin::initPlugin( Identity/Data/Foundations/InformationSystem.Requisitos ) is OK
| 2008-08-28 - 11:22 | - EditTablePlugin::commonTagsHandler( Identity/Data/Foundations/InformationSystem.Requisitos )
| 2008-08-28 - 11:22 | - EditTablePlugin::commonTagsHandler( Identity/Data/Foundations/InformationSystem.Requisitos )
| 2008-08-28 - 11:22 | - TWiki::Plugins::EditTablePlugin::initPlugin( Identity/Data/Foundations/InformationSystem.Requisitos ) is OK
| 2008-08-28 - 11:22 | - EditTablePlugin::commonTagsHandler( Identity/Data/Foundations/InformationSystem.Requisitos )

-- JoaoSRibeiro - 28 Aug 2008

Please refer to the NotWorkingEditTableAndSpreadsheet

It seems that there is a bug while using the combination of EditTablePlugin and SpreadsheetPlugin

-- AmitTendulkar - 03 Sep 2008

I'm not using SpreadSheetPlugin.

This situation is weird, since everything seems to be working fine, but after editing a table and clicking "Save", it just reverts to the initial version of the table, it doesn't save the changes.

-- JoaoSRibeiro - 03 Sep 2008

Im having the same issue as Ian Collier with regards to using LDAPContrib for LDAP authentication. LDAP users can view the topics with an EditTable in them, even edit those topics. But when clicking the Edit button on the bottom of the table as an LDAP user I get the same error. Also I am able to edit the Table as the admin account.

Has anyone found a solution for this?

Any help would be much appreciated!

-- JuliaJacobs - 17 Sep 2008

I found Ian's solution regarding removing the ALLOWCHANGE and ALLOWVIEW users / groups from the webs permissions.

I'll try that . . .

-- JuliaJacobs - 17 Sep 2008

Got that wrong. Ian said "pages with ALLOWTOPICCHANGE or ALLOWTOPICVIEW set". The thing is I was able to edit that table with an LDAP user by removing the ALLOWCHANGE and ALLOWVIEW users / groups. Weird Stuff.

-- JuliaJacobs - 17 Sep 2008

Anyone else had the following issue:

When I click the "X" button to delete a row, it seems to work fine, except if it's the last row, in which case it deletes in edit mode, but reappears once I hit "Save Table".

I also noticed that "Add Row" did not work when my EDITTABLE tag came before my TABLE tag. When the TABLE tag was put above EDITTABLE, then Add Row suddenly started working.

Love the concept and general functionality of this plugin though.

-- GarySprague - 17 Sep 2008

I upgraded my 4.1.2 installation to the latest version of that plugin and now I'm getting the following error message upon clicking the edit table button:

TWiki detected an internal error - please check your TWiki logs and webserver logs for more information.

Can't locate TWikipath in @INC (@INC contains: . path path path path-linux-thread-multi path path path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path path path path path path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path path path path path path-linux-thread-multi path . path)

-- StephaneLenclud - 23 Sep 2008

Just fixed my issue turns out I was missing the BehaviourContrib. That new drag drop row sounds fun I just don't know were to drop my rows?!

  • Between other rows. If all is well you get feedback. Any ideas how to improve visual feedback are welcome! -- ArthurClemens - 24 Sep 2008

-- StephaneLenclud - 24 Sep 2008

Every time you save your tables it adds extra stars around the headers column label. So after 3 saves your header label looks like ***MyHeader***.

To workaround that problem your can specify the header parameter like: %MYEDITTABLE{header="| Header1 | Header2 | Header3 |"}%

-- StephaneLenclud - 24 Sep 2008

Thanks Arthur, fantastic turn around time! I noticed another minor bug. When you just have an EDITTABLE with a header parameter and no table and then click the edit button it creates only the first column.

-- StephaneLenclud - 26 Sep 2008

I reopened Support/EditTableButtonTopAndBottom in the hopes that someone with more JS knowledge than I have will take pity on me. The JS on that page (thanks Arthur!) allows an EditableTable to have the edit button at both top and bottom. Unfortunately, it only works (as written) if there is one and only one table on the page.

I'd love for it to work for any number of tables.

-- VickiBrown - 13 Oct 2008

I think the EditTablePlugin may need a little fix below. In the version used on my wiki site it was not possible to have a wiki link on option list, like that:

%EDITTABLE{ format="select, 1, [[Link]]" }%
|  |

An "Edit" action would convert it to a plain word "Link".

Index: Core.pm
===================================================================
--- Core.pm    (version 31)
+++ Core.pm    (version 32)
@@ -963,6 +963,7 @@
           $valExpanded   =~ s/^\s+//;
           $valExpanded   =~ s/\s+$//;
+           TWiki::Plugins::EditTablePlugin::encodeValue($val) if $val;
           if ( $valExpanded eq $expandedValue ) {
               $text .= " <option selected=\"selected\">$val</option>";
           }

Sorry for spamming you, but I haven't found any reasonable place in the huge TWiki site to put a comment like this.

-- KrzysztofNosek - 03 Nov 2008

(posting above comment for Krzysztof)

-- PeterThoeny - 07 Jan 2009

Issue: Using EditTablePlugin and VIEW_TEMPLATE together

  • All the edittables in a topic are opened at once when I press the edit button on any one of them
Conditions:
  • I created a VIEW_TEMPLATE like this...
    %TMPL:INCLUDE{"view"}%
    %TMPL:DEF{"content"}%
    %TABLE{%TABLEPLUGIN_TABLEATTRIBUTES%}%
    ---+++ Company Information
    %INCLUDE{"%BASETOPIC%" section="sec001"}%
    %BR%
    ---+++ Value Proposition
    %INCLUDE{"%BASETOPIC%" section="sec002"}%
    %BR%
    %TMPL:END%
    
  • I created a topic that uses the VIEW_TEMPLATE like this...
    <!--
       * Set VIEW_TEMPLATE = Sandbox.CdtgViewTemplateXYZ
    -->
    %STARTSECTION{name="sec001" type="section"}%
    %EDITTABLE{format="| text, 20, Main.TWikiGuest | text, 25, Default | radio, 1, Stat1, Stat2, Stat3 | text, 40, http: | textarea, 5x30, Next Step |" changerows="off" quietsave="off" headerislabel="on" header="| *Researcher* | *NetApp Dir* | *Status* | *Company Website* | *Next Step* |"}%%TABLE{dataalign="center, center, center, left, left" headerrows="0"}%
    | *Researcher* | *NetApp Dir* | *Status* | *Company Website* | *Next Step* |
    |  |  |  |  |  |
    %BR%
    %ENDSECTION{name="sec001" type="section"}%
    
    %STARTSECTION{name="sec002" type="section"}%
    %EDITTABLE{ format="| radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | radio,1,Y,N | textarea, 5x30, Product Offerings |" changerows="off" quietsave="off" headerislabel="on" header="| *A* | *B* | *C* | *D* | *E* | *F* | *G* | *H* | *I* | *J* | *K* | *L* | *M* | *N* | *O* | *Company Description* |"}%%TABLE{dataalign="center, center, center, center, center, center, center, center, center, center, center, center, center, center, center, left" headerrows="0"}%
    | *A* | *B* | *C* | *D* | *E* | *F* | *G* | *H* | *I* | *J* | *K* | *L* | *M* | *N* | *O* | *Company Description* |
    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    %BR%
    %ENDSECTION{name="sec002" type="section"}%

NOTE: Tested on TWiki-4.2.3, Wed, 06 Aug 2008, build 17396

  • Same issue with both EditTablePlugin and EditRowPlugin
  • Same issue on twiki.org

Example Files:

-- BurtWelsh - 27 Jan 2009

I havent found this in the discussion. I am trying to create templates for complicated table headers I want to distribute across a system. So I define a variabe, let's call it %SYSTEMSTABLEHEADER% in the WebPreferences and give it a value like this:

   * Set SYSTEMSTABLEHEADER = %EDITTABLE{ format="| select, 1, V240z, E10K | select,1, Solaris 9, Solaris 10, Win 2003, Vista, Windows 7 | radio, 1, 1, 2, 3, 4 | 
select, 1, 1024MB, 2048MB, 4096MB, 8192MB, 16384MB | text, 10 | text, 15 | radio, 2, yes, no | text, 20 |" changerows="off" }% 

If I do this, then go to another page and call the variable %SYSTEMSTABLEHEADER%, I will get an editable table and all, but the changes will not be saved, no matter what I do. Could not figure out why. Any help on this?

-- IngoFechtel - 2009-09-03

I've just upgraded from 4.1 to 4.3 & I notice this statement "Any TWiki variable inside a table cell will be preserved. For instance, %TOPIC% will not get expanded to the current topic name. " - I have many tables with CALC formulae in them which are now just ignored when in edit mode - This is damn ugly (I know they are displaying old versions of the calcs, but at least they are not showing long meandering folumae all over the screen) & actually breaks several of my "mashups" (were a table further down the topic relies on speadsheet variables in the editable table)

I take it this is intentional?

I'm at a bit of a loss as to know what to do next. It would be nice to have a switch for this non-expansion feature, or at least for TWiki to honour the order of plugins & do the CALC before the edit

-- ChrisHogan - 2009-10-31

Is there a way to get EditTablePlugin to increment the page history on save?

-- CameronWood - 2010-05-27

This is currently not supported. The plugin could be enhanced to show an optional "force new revision" checkbox. TWiki is an open source project, you can enhance the plugin or sponsor the enhancement.

-- PeterThoeny - 2010-05-28

Peter,

It appears that the EditTablePlugin/Core.pm file has an error in it (at least on my system..)

"my" variable %regex masks earlier declaration in same scope at /var/www/twiki/lib/TWiki/Plugins/EditTablePlugin/Core.pm line 54.

By commenting out the "my %regex;" on line 46 the plugin functions again.

-- JudBarron - 2012-07-05

Thanks Jud for reporting with fix. Tracked in TWikibug:Item6900. Now fixed in SVN trunk, TWiki-5.1 branch, and released at Plugins.EditTablePlugin.

-- PeterThoeny - 2012-07-11

Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm Core.pm r3 r2 r1 manage 49.7 K 2008-01-24 - 14:14 UnknownUser Updated Core.pm with expanded variables in radio, select and checkbox format
Compressed Zip archivezip EditTableMergePlugin.zip   manage 115.5 K 2004-12-27 - 14:55 UnknownUser  
Compressed Zip archivetgz EditTablePlugin-Dynamic.tgz r1 manage 42.3 K 2007-03-01 - 20:15 UnknownUser EditTablePlugin with Javascript support for manipulating rows more easily. Works with TWiki 4.X.
Compressed Zip archivezip EditTablePlugin-JSCalendarContrib.zip r1 manage 42.0 K 2005-02-07 - 03:35 UnknownUser Leverages JSCalendarAddOn
Unknown file formatpatch EditTablePlugin-cn.patch   manage 0.9 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePlugin-datedefault.patch   manage 2.6 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePlugin-quietsave.patch   manage 3.3 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePlugin.12Apr2003.patch   manage 5.8 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatdiff EditTablePlugin.diff   manage 0.6 K 2005-02-19 - 02:00 UnknownUser  
Perl source code filepm EditTablePlugin.pm   manage 27.9 K 2005-02-19 - 02:00 UnknownUser  
Perl source code filepm EditTablePluginAltern.pm   manage 32.6 K 2004-07-14 - 20:09 UnknownUser  
PNGpng EditTablePluginAlternPicture.png   manage 22.4 K 2004-06-03 - 11:43 UnknownUser  
Unknown file formatpatch EditTablePluginDefaultChangeRows.patch   manage 0.4 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePluginExpanseVars.patch   manage 2.2 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePluginExpanseVars2.patch   manage 1.1 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePluginExpanseVars3.patch   manage 2.0 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePluginGreyOddRows.patch   manage 1.5 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatdiff EditTablePluginLineBreaks.diff   manage 1.9 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTablePluginMoveLockRows.patch r1 manage 3.2 K 2004-08-18 - 16:12 UnknownUser Protect from edit or move rows containing a keyword
Unknown file formatdiff EditTablePluginTextArea.diff   manage 1.9 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatdiff EditTablePluginTextAreaDoc.diff   manage 3.3 K 2005-02-19 - 02:00 UnknownUser  
Unknown file formatpatch EditTable_selectvals.patch r1 manage 1.5 K 2004-04-29 - 09:10 UnknownUser select items can have value param
Texttxt EdittablePlugin-Core-checkbox-spaces-patch.txt r1 manage 0.5 K 2008-02-15 - 08:40 UnknownUser Patch to remove space before comma between checkbox entries
Texttxt EdittablePlugin-Core-uninitialized-values-patch.txt r1 manage 0.6 K 2007-09-27 - 17:22 UnknownUser Patch to avoid getting uninitialized values errors
Compressed Zip archivetgz TWiki-4.0.2-EditTablePlugin-MoveRowDynamically.tgz r3 r2 r1 manage 23.7 K 2006-05-24 - 17:07 UnknownUser Allows rows to be moved quickly, efficiently.
Unknown file formatpatch edittable.patch r1 manage 4.3 K 2004-04-27 - 16:44 UnknownUser Patch to fix select issue and update jscalendar
Unknown file formatpatch edittable_cells.patch r1 manage 4.5 K 2007-02-21 - 11:29 UnknownUser Experimental Core.pm update to add cells parameter (possible way to solve editcell issues)
Edit | Attach | Watch | Print version | History: r394 < r393 < r392 < r391 < r390 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r394 - 2020-04-26 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.