Tags:
create new tag
, view all tags

EditTablePluginDev Archive

These are older EditTablePlugin discussions moved from EditTablePluginDev

-- PeterThoeny - 22 Apr 2004


This functionality is nice. I'd like to suggest two things:

  • Do not use "viewauth" in line 348 in EditTablePlugin.pm but replace by "view".
  • This would be even better if we could keep the size of the cell fixed in the designated space, but wrap the text in the cell, if it exceeds that size (rather than growing the table).

One problem with Twiki tables is that they don't give you a convenient way of keeping the size. Cells grow unlimited to the right, if one is not careful to break the lines...

-- ThomasWeigert - 05 May 2002

I would like to suggest the addition of the format option off to deactivate the edit of given columns. This is useful when changecolums is off and you just want to allow update of some columns.

I would like to suggest also the new parameter addonly that (if "on") should allow the addition and editing only of the last line.

I attach below a patch implementing the off format option.

-- AndreaSterbini - 16 May 2002

Anoter small bug: When including parameters from another topic, the code scans for a closing }%, this prevents having %-parametrized-vars in init values or others (very useful to put today's date as init value of a field for instance). My patch (EditTablePlugin-cn.patch: allow %-vars in included parameters) does 2 things:

  • allows one to "quote" the included vars closing }% with a nop, this way: }<nop>%
    e.g.: format="|text,10,06 Oct 17}<nop>%|"
  • expands these vars when coming from included topic after the "de-quoting"

-- ColasNahaboo - 18 Jun 2002

After a good sleep, I found a cleaner way: Since the included topic's %EDITTABLE% must be on one line, just gobble in a greedy way everything on the line upto a ==

This wont work if there are two %EDITTABLE% on the same line, but it should never happen, and avoids the unnatural requirement of using }<nop>%. The proper way should be of course to properly match nested %NAME{ and }%...

I updated EditTablePlugin-cn.patch, be sure to take the 19 Jun 2002 version.

-- ColasNahaboo - 19 Jun 2002

First I must say that I really enjoy the EditTablePlugin. It makes table creation and maintenance much easier(or even possible) for our users. Maybe it is also possible to add these two features to this plugin:

  • Make table sortable when editing by using TablePlugin
    • When you look at the page it is sorted after the enter sequence. It would be nice to pre sort the table, so that it is already sorted when you look at the page. Perhaps that is rather an TablePlugin feature, when you say which column should be sorted as you arrive at a page.

  • Delete selected rows
    • It would be nice to delete rows after they where selected with a checkbox.

-- AndreUlrich - 03 Jul 2002

Presorted tables: This is a TablePlugin feature. You should be able to use both plugins, specify %TABLE{}% before %EDITTABLE{}%.

-- PeterThoeny - 04 Jul 2002

I really like this plugin smile

BUG: An existing table that uses variables in any of the cells gets expanded when the table is edited. The expansion remains when the table is saved.

Specifying the row number to be deleted or inserted would be nice. If a table that implements a Spreadsheet (via plugin) is edited to add a new row (but not the last row, since that often has the equations, etc.), you have to cut and past row contents to maintain the existing last row as the new last row.

-- MartyBacke - 09 Jul 2002

Is anybody else seeing a problem with anchors not being passed through the "Edit table" button with Opera 6.04? Basically in Opera after clicking on "Edit table" I am left at the top of the page, with the table enabled for editing. This same action jumps me to the table to be edited in IE.

When I click on the edit table button in opera, the displayed URL is:

http://192.168.1.20/twiki/bin/viewauth/TWiki/EditTablePlugin
but I think I am supposed to see:
http://192.168.1.20/twiki/bin/viewauth/TWiki/EditTablePlugin#edittable1
If I type in the expected URL, my browser jumps to the table.

Also what do people think of this set of functions for lock primatives in Func.pm for the plugins? It would be nice to cobble it into BeijingRelease, but I think its to late for that. Since this plugin relies on undocumented functions for locking and CommentPlugin could benefit from some locking functions: I am thinking of the following interface:

  • ($lockStatus, $lockedBy, $lockedWhen, $lockError) = lockTopic($web, $topic) to lock a topic. Where:
    • $lockStatus = 0 if lock succeeded, and lockedBy and lockedWhen are current user and time() respectively, $lockError is empty.
    • $lockStatus = 1 if lock failed because topic already locked and lockedBy and lockedWhen are the appropriate values telling us who locked the topic, $lockError is empty, or "already locked".
    • $lockstatus = 2 if lock failed because of mechanical problem. I.E. can't write to disk etc. $lockedBy, $lockedWhen are empty, $lockError is the cause of the error.
  • ($lockStatus,$lockedBy, $lockedWhen, $lockError) = testTopicLocked($web, $topic) Can be used to see if a lock is stolen (i.e. $lockedBy = current user), or if the topic is avaiable for update (e.g. CommentPlugin may not render textbox if topic is already locked). This has basically same semantics as lockTopic but:
    • $lockStatus = 0 if you could have gotten a lock at the time the call was done. $lockedBy and $locked empty since lock not actually done, $lockError is empty.
    • $lockStatus = 1 if lock attempt would fail because topic already locked. $lockedBy and $lockedWhen are the appropriate values telling us who locked the topic, $lockError is empty, or "already locked".
    • $lockstatus = 2 will never be returned since no attmpt to make a lock is done.
  • releaseLock($web, $topic) returns 0 for success, 1 for failure because topic not locked by user.

-- JohnRouillard - 04 Aug 2002

A few more things after working with this plugin. Its great and has helped solve a couple of potential problems. Can't wait to use it with the phone list 8-).

However, it looks like the use of % vars in EditTablePlugin's parameters may not be totally fixed. I tried the nop methods that Colas mentioned above on the off chance that there may still be that legacy code in Peter's patch. No joy. See SearchInEditTableFormatBreaksEditTable for the gory details.

Also, it looks like the Edit Table button is really active even in preview mode. Shouldn't it have the same link to an oops page that everything else has when in preview mode?

-- JohnRouillard - 08 Aug 2002

Possible bug: I find that sometimes when I used the feature, it simply doesn't work. The problem seems fairly random. In some topics, it works perfectly as advertised (and I love it). But I can copy and paste the exact same table into another topic, and the is just ignored. The table is there, but no "edit" button. I can't identify anything special about the topics in which it fails.

Has anyone else seen this?

-- MarkThomson - 23 Aug 2002

Yes. We found that this happens if the table is not followed by an empty line

-- ColasNahaboo - 28 Aug 2002

As this plugin is more and more used at work, we stumble on performance issues. People with tables of ~ 50 lines have clicking on "Add row" make the server go into 100% cpu groking perl code for... 1 minute real time!

I will try to have a go, but at a glance the big loop on each line seems the obvious culprit

-- ColasNahaboo - 18 Sep 2002

Re: cases where the plugin does not work - it also fails if the EDITTABLE entry is the last line in the file. The table just did not appear. Had me stumped for a while. I could get the table to show up by changing line 196 to check for the eof condition as well as the blank line condition, however then the save option no longer worked.

-- MartinWatt - 27 Sep 2002

Another little buglet - if a label uses the *name* format this gets mangled when going to the edit mode, and does not come back right. eg "label,0, *Task*" gets converted to

</strong>Task*

-- MartinWatt - 27 Sep 2002

One other UI issue, it would be nice if there were a column of check boxes down the left hand side of the table when in an edit mode that allows changerow. This way you can select which row(s) to delete and also select which row(s) to add entries before. With no rows selected, a new row would be added at the end of the table. I often find myself wanting to delete a row that is not the last in the table.

-- JohnRouillard - 28 Oct 2002

It seems to me that EditTablePlugin is not well integrated with the TablePlugin. I tried to get the automatic sorting to work to no avail.... I suggest to support all the fields supported in TablePlugin.

It is more than awkward if one way of creating tables supports features such as initial sorting, cell coloring, cell border settings, alignment, etc., but another kind of table, which from the user's point of view is only different in that it can be edited, does not.

-- ThomasWeigert - 06 Nov 2002

Thomas: Agreed, this should be supported. For now I posted the limitations in the Plugin topic.

-- PeterThoeny - 09 Nov 2002

Spearking from a user point of view, I think that EditTablePlugin and TablePlugin should be merged into a single plugin, with the ability of editing a table being one of the options. This for the following reasons:

  • Both forms of tables would support the same functionality (e.g., coloring cells, alignment, border settings, etc.)
  • It will be more likely that these two forms of tables remain consistent in their features
  • Any other plugins that operate on tables (e.g., FormPivotPlugin) would work on both editable and non-editable tables
  • There may also be some performance issue as no searching for two kinds of table variables is necessary.

-- ThomasWeigert - 09 Nov 2002

I agree with Thomas, merging the two plugins would be a fantastic benefit for folks using them. Yes, I know I could should do it myself, but Im busy working on generalizing the DatabasePlugin right now....

-- JohnCavanaugh - 22 Nov 2002

It would be useful if there was a way to restrict a column to accept only numeric values...

-- MartinWatt - 24 Nov 2002

Using the EditTablePlugin with the XpTrackerPlugin, I get a recurring message in the Apache error_log whenever I add a row:

    viewauth: Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/Plugins/EditTablePlugin.pm line 491.
A quick fix was:
--- EditTablePlugin.pm.bak      2002-11-08 18:34:28.000000000 -0800
+++ EditTablePlugin.pm  2003-01-01 03:25:39.000000000 -0800
@@ -488,6 +488,7 @@
 {
     my ( $thePre, $theRow, $theTableNr, $theRowMax, $theRowNr, $doEdit, $doSave ) = @_;
 
+    if (!defined($thePre)) { $thePre = ""; }
     my $text = "$thePre\|";
 
     if( $doEdit ) {

-- AnthonPang - 01 Jan 2003

Just to pile on another suggestion...

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

And now for something completely different cool!

I recently made an extension to the EditTablePlugin so that it now understands an additional format specifier, i.e. textarea. Syntax example:

  textarea, 3x30, defaulttext

The change is in function inputElement and is only 10 lines or so. This makes is much easier to edit tables with not-so-terse text fields. Hope it's useful to others as well. If this is not the proper way to post extensions/patches, I apologize and ask for guidance on how to proceed. Tnx!

*** /var/tmp/,RCSt1a21503   Tue Feb 25 15:30:13 2003
--- /var/tmp/,RCSt2a21503   Tue Feb 25 15:30:13 2003
***************
*** 449,455
          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text .= "<input type=\"hidden\" name=\"$theName\" value=\"$theValue\" />";
  
!     } else {  # if( $type eq "text" )
          $size = 16 if $size < 1;
          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text = "<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />";

--- 449,463 -----

          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text .= "<input type=\"hidden\" name=\"$theName\" value=\"$theValue\" />";
  
!     } elsif( $type eq "textarea" ) {
!         my ($rows, $cols) = split( /x/, $size );
!         $rows = 3 if $rows < 1;
!         $cols = 30 if $cols < 1;
! 
!         $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
!         $text .= "<textarea rows=\"$rows\" cols=\"$cols\" name=\"$theName\">$theValue</textarea>";
!         
!     } else { #  if( $type eq "text") 
          $size = 16 if $size < 1;
          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text = "<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />";
***************
*** 453,459
          $size = 16 if $size < 1;
          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text = "<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />";
!     }
      return $text;
  }
  

--- 461,467 -----
          $size = 16 if $size < 1;
          $theValue = $encodeStart . encodeValue( $theValue ) . $encodeEnd if $theValue;
          $text = "<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />";
!     }  
      return $text;
  }

-- ClausBrod - 25 Feb 2003

Patch looks good - got it installed here and running. Very useful too - we have users complaining about editing text in tables on a single line, so this will help a lot. Thanks.

-- MartinWatt - 26 Feb 2003

One problem with the above text area extension is that line breaks are stripped from the input fields when the table is saved. That's a little inconvenient, but not so difficult to fix. I attached my solution here:

Line breaks are now converted to <br /> when a table is saved, so for displaying a table, nothing has to be done to the table. When a table is edited, the <br /> is converted to the unicode line break character &#10; - inserting a regular line break will break other code.

-- JohannesMartin - 26 Feb 2003

Another suggestion (without code... ;-( )

Allow for a header parameter that makes the first column uneditable, similar to what is already there for first header row. It would make for editing table like the following much easier.

Name Foo Bar
Rank Captain
Serial Number 8675309
...

-- JohnCavanaugh - 17 Mar 2003

That would be possible with the label type for the first column?

-- PeterThoeny - 18 Mar 2003

Peter, thanks for the pointer, which of course resulted in the obligatory, Duh...

However it is close but not quite correct. Somehow the left column doesnt get "wikified" when going to the edit mode, namely the label becomes surrounding by asteriks instead of being bold. See example below.

Name Foo Bar
Rank Captain
Serial Number 8675309

Will this be another "Duh..." moment for me or is this in fact a defect??

  • That sounds like a defect in the Plugin -- PeterThoeny - 22 Mar 2003

-- JohnCavanaugh - 19 Mar 2003

I've been using EditTablePlugin a lot recently and find it very useful, particularly with folks that are not up to speed with TWiki syntax. Here's my top "wish-list" items for making it even more user-friendly:

  • Ability to delete selective rows (as mentioned previously).
  • Option of designating another topic for listing multiple options (as with TWikiForms).
    • Couldn't you use the include parameter for that? -- PeterThoeny - 22 Mar 2003
  • Option to allow editing (or limited editing) by non-registered users (as with CommentPlugin).

-- LynnwoodBrown - 19 Mar 2003

On tables with lots of rows I have found it hard to read since the alternating row colors are not visible. Here is a quick one liner that I have used to make things a little easier on the eyes...

Change line 481 from
   $text = "<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />";
to
   $text = "&amp;nbsp;&amp;nbsp;&amp;nbsp;<input type=\"text\" name=\"$theName\" size=\"$size\" value=\"$theValue\" />&amp;nbsp;&amp;nbsp;&amp;nbsp;";

-- JohnCavanaugh - 21 Mar 2003

I made another patch, that I suggest be included in the main sources: EditTablePluginExpanseVars.patch: patch to 08 Nov 2002 version: allow %vars in ops

It allows for %-vars to be used in "select" fields, to be able to use icons in it. See for example: http://koala.ilog.fr/wiki/bin/view/Test/TestIconsInTables (the last column).

Without this patch, when editing, all the values are reset to the first one (the contents of the table was processed, but not the format definition of select, so the code could not see that a value already entered was matching a predefined value)

-- ColasNahaboo - 08 Apr 2003

On the same idea as John's patch, but this time with styling the input fields: even rows are default (white), odd light grey. (I found that not reusing the "view" colors make it clearer that we are in edit mode) EditTablePluginGreyOddRows.patch: greys odd rows (style)

If you applied the textarea patch, replace also the string(s) <textarea by the strings <textarea$style

-- ColasNahaboo - 08 Apr 2003

Another patchlet: EditTablePluginTextAreaDoc.diff: patch to the doc topic for the textarea patch

This just documents the effects of the textarea patch in the data/TWiki/EditTablePlugin topic (I manage 5 wiki webs, so when I apply modifications I always do a patch myself to replicate it, so I post it here for others convenience)

-- ColasNahaboo - 08 Apr 2003

Patch patch patch patch patch... FAIL.

mrjcleaver@mrjcPLEASENOSPAM.com [~/www/mbs]# patch <patches/EditTablePluginTextArea.diff can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was:


|*** /var/tmp/,RCSt1a21503 Tue Feb 25 15:30:13 2003 |--- /var/tmp/,RCSt2a21503 Tue Feb 25 15:30:13 2003
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm patching file lib/TWiki/Plugins/EditTablePlugin.pm Hunk #1 succeeded at 488 with fuzz 1 (offset 39 lines). Hunk #2 FAILED at 500. 1 out of 2 hunks FAILED -- saving rejects to file lib/TWiki/Plugins/EditTablePlugin.pm.rej

I don't mind patching (though many would)... unless it fails. Then I think to myself, surely there is an easier way.

  • Clearly I have installed the patches in the wrong order. Anyone fancy checking in a new version and building a zip file? DeveloperVersionInCVS = yes. In the meantime I'll live without the plugin.

    • To address the issue about whether a Plugin author wants you to modify their code, I've just added a field CVSModificationPolicy to the WebForm. To my surprise though the field did not get added to the webform on EditTablePlugin. Sigh.

-- MartinCleaver - 10 Apr 2003

CVSModificationPolicy is in the form when I edit. What be a good idea to put a definition in this new topic.

-- JohnTalintyre - 11 Apr 2003

(off-topic) I guess I had expected it to appear when viewed, as otherwise a person wouldn't know that they need to edit.

-- MartinCleaver - 12 Apr 2003

So, I thought to myself: there's no point me wingeing about the bubblegum and stickytape and expecting someone else to fix it, I'll do the patches in the correct order and repost a new EditTablePlugin.pm. No good, I'm afraid...

mrjc.com [~/www/mbs/patches]# unzip EditTablePlugin.zip
Archive:  EditTablePlugin.zip
  inflating: lib/TWiki/Plugins/EditTablePlugin.pm
  inflating: data/TWiki/EditTablePlugin.txt
  inflating: data/TWiki/EditTablePlugin.txt,v

mrjc.com [~/www/mbs/patches]# patch < EditTablePluginTextArea.diff
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|*** /var/tmp/,RCSt1a21503      Tue Feb 25 15:30:13 2003
|--- /var/tmp/,RCSt2a21503      Tue Feb 25 15:30:13 2003
--------------------------
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm
patching file lib/TWiki/Plugins/EditTablePlugin.pm
Hunk #1 succeeded at 475 (offset 26 lines).

mrjc.com [~/www/mbs/patches]# patch < EditTablePluginLineBreaks.diff 
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|*** EditTablePlugin.pm.old     Wed Feb 26 12:47:26 2003
|--- EditTablePlugin.pm Wed Feb 26 12:49:38 2003
--------------------------
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm
patching file lib/TWiki/Plugins/EditTablePlugin.pm

mrjc.com [~/www/mbs/patches]# patch < EditTablePluginExpanseVars.patch
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|*** lib/TWiki/Plugins/EditTablePlugin.pm.orig  Tue Apr  8 16:34:04 2003
|--- lib/TWiki/Plugins/EditTablePlugin.pm       Tue Apr  8 16:31:14 2003
--------------------------
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm
patching file lib/TWiki/Plugins/EditTablePlugin.pm
Hunk #2 succeeded at 364 (offset 3 lines).
Hunk #4 succeeded at 452 (offset 3 lines).

mrjc.com [~/www/mbs/patches]# patch <  EditTablePluginGreyOddRows.patch
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|*** lib/TWiki/Plugins/EditTablePlugin.pm.orig  Tue Apr  8 16:59:24 2003
|--- lib/TWiki/Plugins/EditTablePlugin.pm       Tue Apr  8 17:16:30 2003
--------------------------
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm
patching file lib/TWiki/Plugins/EditTablePlugin.pm
Hunk #1 succeeded at 446 with fuzz 2 (offset 11 lines).
Hunk #2 FAILED at 490.
1 out of 2 hunks FAILED -- saving rejects to file lib/TWiki/Plugins/EditTablePlugin.pm.rej

mrjc.com [~/www/mbs/patches]# patch < EditTablePluginTextAreaDoc.diff
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|*** data/TWiki/EditTablePlugin.txt.orig        Tue Apr  8 18:51:09 2003
|--- data/TWiki/EditTablePlugin.txt     Tue Apr  8 18:56:14 2003
--------------------------
File to patch: lib/TWiki/Plugins/EditTablePlugin.pm
patching file lib/TWiki/Plugins/EditTablePlugin.pm
Hunk #1 FAILED at 20.
1 out of 1 hunk FAILED -- saving rejects to file lib/TWiki/Plugins/EditTablePlugin.pm.rej


A few observations:

  1. The PatchGuidelines need to include a review process for the TWikiPatchMaster to accept administrative responsibility for the usability of patches. Cruicially this includes:
    1. Thanking the submitter for the patch
    2. The right paths in the patch files
    3. Testing of cumulative patches
    4. Rejection of unsuitable or unusable flags, notification of the submitter that there is a problem together with an invitation to fix
    5. Application for the patch to make it into the core of TWikiAlpha, TWikiBeta and TWikiRelease, as outlined by Colas in WebFormReorg. Perhaps TWikiAlphas are too stable: as I don't see instability warnings this indicates that few or no risks are being taken on each marginal release. 2 This time I (think I) did the application of the patches in the right order. It still failed.
    6. Colas: as it was your EditTablePluginGreyOddRows.patch that first failed, can you please either have a go at applying these in the same order as I did or post a new consolidated lib/TWiki/Plugins/EditTablePlugin.pm including and upto your last patch? I'm guessing this is easy for you as you can just lift it off your installation.

-- MartinCleaver - 12 Apr 2003

I thought it somewhat odd that you would want to allow people to edit a table and then by default prevent them adding rows to it. I submit this patch to alter the default.

I notice that the CVSModificationPolicy for this Plugin is 'ContactAuthorFirst' - is there a new version planned? There are many patches submitted.

-- MartinCleaver - 04 May 2003

Sorry I did not see your post before, Martin. Here is my cumulative patch. It includes only chnages to the .pm, not the doc, and not your changes of the 4 May (but which should apply without problems)

-- ColasNahaboo - 06 May 2003

Unless I am mistaken, applying changes to the table does not roll the revision of the page. Is this a misconfiguration, or an omission?

-- SeanBoyle - 19 May 2003

You probably see no new version because you save the same topic within one hour. This is TWiki spec, to save unnecessary revisions.

-- PeterThoeny - 21 May 2003

For reasons of layout, I am using tables, in which rows and columns are switched, something like

Field Content
id 1
year 2003
type Book
...  

is it possible to tweak the EditTablePlugin to work with that type of tables? I am especially interested in having different types of content fields, depending on the value of Field.

-- MartinRehker - 27 May 2003

New patch:

This adds besides the "Save table" a new button "Quietsave" that saves without triggering the notification mecanism (just like Quietsave of the skins with the Savemulti functionality, or checking the "minor edit, do not notify" checkbox of the standard skin. It was requested by users.

I also attach the current state of the lib/TWiki/Plugins/EditTablePlugin.pm file for reference, with all patches on this page up to 12 Jun 2003 applied, to act as a cumulative patch. I suggest patch authors may maintain this file, acting de facto like a poor-man CVS smile

-- ColasNahaboo - 12 Jun 2003

Has anybody done any work on supporting justification of cells with the edit plugin?

-- JohnRouillard - 25 Jun 2003

Tables at the end of topics, i.e. those with only blank lines or no lines following them, do not display the "Edit table" button. In fact, the displayed HTML page does not correctly terminate the <form> construct with </form>, either.

A fix for this is to add the following line into the EditTablePlugin.pm file. I have added it after line 135 " my $cgiRows = -1;"

$_[0] .= "\n<!-- Temporary comment -->";

This ensures that handleTableEnd is always called so that the Edit table button is added and the form is correctly closed off. The current erroneous operation of the script is that handleTableEnd is not called at all at the end of the topic.

-- PeterAlbiez - 16 Jul 2003

Fix above applies to ColasNahaboo's 12 Jun version. It would be really nice if someone could check in all these fixes and republish! PeterThoeny owns the plugin.....?

-- CrawfordCurrie - 17 Jul 2003

I found some strange behaviour in my installation of EditTablePlugin (Version: 08 Nov 2002) When I insert words with uppercase letters (not necessarily WikiWords, just words like "Foo Bar") into a cell, I get things that look like this: Foo Bar. That is, the first word is ok, all the other words starting with an uppercase letter have their first letter turned into a (non-existing) link. The html code I get is this:

Foo <span style='background : #FFFFCE;'><font color="#0000FF">B</font></span>
<a href="/twiki/bin/edit/Sandbox/B?topicparent=SandboxNowikowKlausSandbox">?</a>ar
When I create a new line and add "Foo Bar" into a cell, everything is ok. But when I press "Edit table", the above code appears in the cell and stays there.

The table is defined as

%EDITTABLE{ header="|*Nr*|*Text field sandbox*|*Drop down sandbox*|*Timestamp*|"
format="| row, -1 | text, 20, init | select, 1, one, two, three, four | label, 0,
%SERVERTIME{"$day $mon $year $hour:$min"}% |" changerows="on" }%
It is the example from the plugin's home topic. The problem also appears in the SERVERTIME column.

-- KlausNowikow - 29 Aug 2003

I am sorry. It appears that the above error was due to an interaction with SingletonWikiWordPlugin. D'uh.

-- KlausNowikow - 29 Aug 2003

Interesting, thanks, I've seen this problem on my site but had not traced its origin. I've copied your problem description to SingletonWikiWordPluginDev.

-- MartinCleaver - 29 Aug 2003

I am working on adding some features to EditTable plugin, details at: EditTable2PluginDev. Features include access control rights on rows and columns, synchronization etc. Requesting review and comments. The '2' is only temporary; to make sure we can test this while retaining existing EditTablePlugin.

-- VinodKulkarni - 05 Sep 2003

Uploaded EditTablePluginExpanseVars2.patch fix for %-vars when adding deleting rows. Previosly select fields would have been reset to first value when adding /deleting a row

I took the opportunity to rassemble all the patches in this topic and make a new, 18 Sep 2003 version including all the patches here.

Warning: I changed also the default of changerows to be on, as this is the most common case, I think the gain warrants this (very small) incompatibility.

-- ColasNahaboo - 18 Sep 2003

I modified the patch above, since it saved the expansed values in the table. It worked, but the resulting table was potentially becoming too verbose: e.g. instead of storing %N%, it was storing the whole <img> html tag it was expansed into. The cumultaive patch to add is EditTablePluginExpanseVars3.patch: fix to .2patch

I upgraded the main plugin distrib with this patch, to version 13 Oct 2003

-- ColasNahaboo - 13 Oct 2003

New version 15 Oct 2003 that use the nice Javascript calendar. No need to upgrade if you do not want to try it.

-- ColasNahaboo - 15 Oct 2003

I detected two "uninitialized values" within EditTablePlugin at line 455 (approx.):

  • original code:
    ...
    my $style = " style='background:#e8e8e8'" if ($theRowNr % 2);
    if( $type eq "select" ) {
        my $expansedValue = &TWiki::Func::expandCommonVariables( $theValue, $theTopic, $theWeb );
      ...
  • replacement:
    ...
    my $style = "";
    $style = " style='background:#e8e8e8'" if ($theRowNr % 2);
    if( $type eq "select" ) {
        my $expansedValue = &TWiki::Func::expandCommonVariables( $theValue, "" , "" );
      ...
The effect of these uninitialized values with Apache 1.3.28 on Win2000 with Cygwin Perl was, that I couln't edit tables with more than 2 rows (no bug fixed) and 10 rows (after fixing the &TWiki::Func::expandCommonVariables( $theValue, "" , "" ) line) respectively.

-- BorisHolzer - 21 Oct 2003

Not sure if this has been addressed, but any %-var tags in a cell cause edit table to return a * on edit, which makes the cell difficult to edit....

-- BenjaminFleischer - 31 Oct 2003

I'm setting up a feature list of different Km Products with features on a vertical and products across the top. I wanted to use the drop downs and specify the types on a per-row basis. It seems that it is only possible to specify per-column, which doesn't match my user's needs as there are far more features than products. (Hence features have to go on the vertical).

Anyone seen this problem and got a solution? I suggested use of category tables but, because we can't navigate a dataset, my user is not interested in that.

-- MartinCleaver - 08 Nov 2003

good job on the new release, works better now, but email addresses in the table with NOSPAM insertions get saved into the text as broken links... only if the cell is text or a textarea without line breaks (<br />) between addresses... e.g. <a href="mailto:pookie@yahoNOSPAMo">pookie@yahooNOSPAMo</a>.com

-- BenjaminFleischer - 15 Dec 2003

I've run into an interesting issue that I have not been able to readily remedy. Here is what I am doing:

- Parent topic has an area that "rolls up" the bottom row of a table in it's children. I do this with:

%TABLE{ sort="off" tableborder="1" cellpadding="1" cellspacing="3" tablewidth="75%" }%
|*Q1*|%INCLUDE{%TOPIC%Q1}%
|*Q2*|%INCLUDE{%TOPIC%Q2}%
|*Q3*|%INCLUDE{%TOPIC%Q3}%
|*Q4*|%INCLUDE{%TOPIC%Q4}%

Each %TOPIC%Q1 is a child topic. Each child topic has the following table:

%TABLE{ sort="off" tableborder="1" cellpadding="1" cellspacing="3" headerbg="#000099" headercolor="#FFFFCC"
databg="#C8CB8F, #DBDDB5" headerrows="1" tablewidth="75%"}%
%EDITTABLE{ header="on" format="| label | text, 10 | text, 10 | text, 10 |" changerows="off" }%
|*Site*|*High Findings*|*Medium Findings*|*Low Findings*|
| Site1 | 10 | 10 | 10 |
| Site2 | 10 | 10 | 10 |
| Site3 | 10 | 10 | 10 |
| Site4 | 10 | 10 | 10 |
| Site5 | 10 | 10 | 10 |
| *Totals*  | %CALC{"$SUM( $ABOVE() )"}%  | %CALC{"$SUM( $ABOVE() )"}%  | %CALC{"$SUM( $ABOVE() )"}%  |
%STARTINCLUDE%|*Totals*|%CALC{"$SUM( $ABOVE() )"}%|%CALC{"$SUM( $ABOVE() )"}%|%CALC{"$SUM( $ABOVE() )"}%|%STOPINCLUDE%

The last line of the table is a "Totals" line and it is this line that is extracted by the %INCLUDE% using the %STARTINCLUDE% and %STOPINCLUDE%.

Let me stop here and say that the above works wonderfully - the Parent is able to "rollup" the totals line of each child. The problem occurs when one clicks on the table "EDIT" button to change the cell data then hits "Save". The last line is replicated with each and every subsequent save. I haven't gone through every permutation of possibility but was wondering if someone would have a sudden epiphany as to why the above would cause EditTablePlugin to replicate that last line. I am using the 12/20/2003 version.


UPDATE

It would appear that the %STARTINCLUDE% %STOPINCLUDE% are the culprits. I removed them and table editing now does not replicate the last row -- but now my "rollup" doesn't work! Would this be considered a bug - where these two Twiki tags are being interpreted by the Plugin as replication directives?

UPDATE2

Ok, I spoke too soon. Apparently the "rollup" does not work - what rolls up is the %CALC% entries and not the calculation results. Back to the drawing board - but it still appears that something in the plugin is interpreting the STARTINCLUDE as a replication directive.

-- SteveRJones - 15 Jan 2004

I am trying to use the EditTablePlugin together with the SpreadSheetPlugin to summarize the information in the Table like above. Is there anyway to make it work? Am I combining the wrong hammers? An easy solution seems to be to support a footer attribute to the EditTablePlugin that can contain variables?

-- KiranBondalapati - 19 Jan 2004

This code:

%TABLE{ sort="off" tableborder="1" cellpadding="1" cellspacing="3" headerbg="#000099" headercolor="#FFFFCC"
databg="#C8CB8F, #DBDDB5" headerrows="1" tablewidth="75%"}%
%EDITTABLE{ header="on" format="| label | text, 10 | text, 10 | text, 10 |" changerows="off" }%
|*Site*|*High Findings*|*Medium Findings*|*Low Findings*|
| Site1 | 10 | 10 | 10 |
| Site2 | 10 | 10 | 10 |
| Site3 | 10 | 10 | 10 |
| Site4 | 10 | 10 | 10 |
| Site5 | 10 | 10 | 10 |
| *Totals*  | %CALC{"$SUM( $ABOVE() )"}%  | %CALC{"$SUM( $ABOVE() )"}%  | %CALC{"$SUM( $ABOVE() )"}%  |

should work fine as long as the %STARTINCLUDE% and %STOPINCLUDE% are not part of the table. I have done this many times on our own internal site and I just re-verified it. We are running the current release of TWiki and the only patch that has been applied is one that allows variable expansion within FORMS - I doubt that would be in effect here.

-- SteveRJones - 19 Jan 2004

But, I do want to leave the table editable to add rows. If I keep changerows then the next edit loses the last summary line.

UPDATE I figured out how to patch the code to make it work. There are some caveats explained after the patch.

EditTablePlugin already supports a footer parameter like the format parameter which is extracted but not handled.

# FIXME: No handling yet of footer

In commonTagsHandler (line 231 in my version) I added this:

if (!$doEdit) { # only do it in view mode and not while editing
  if ($footer) {
    $footer =~ s/\"/\"/gos;   # expand double quote
    $footer =~ s/\&dollar/\$/gos;   # expand double quote
    $footer =~ s/\&percent/\%/gos;   # expand double quote
                     
    $result .= $footer . "\n";
  }
}
before the line:
$result .= handleTableEnd( $theWeb, $rowNr, $doEdit );
and in the header I can defined the footer as
... footer="| Total: &percentCALC{" &dollarROW(-2) "}&percent | | |&percentCALC{"&dollarCOUNTITEMS( R2:C&dollarCOLUMN()..R&dollarROW(-1):C&dollarCOLUMN() )"}&percent | &percentCALC{"&dollarCOUNTITEMS( R2:C&dollarCOLUMN()..R&dollarROW(-1):C&dollarCOLUMN() )"}&percent | &percentCALC{"&dollarCOUNTITEMS( R2:C&dollarCOLUMN()..R&dollarROW(-1):C&dollarCOLUMN() )"}&percent | | &percentCALC{" &dollarSUM( &dollarABOVE() )" }&percent | | |"  ...

Since SpreadSheetPlugin seems to get called after EditTablePlugin (I did not have to enforce ordering), the footer is formatted properly and SpreadSheet can do arbitrary calculations on the same table.

(BTW, I also had to comment out the following lines in handleEditTableTag):

    #$footer =~ s/^\s*\|//o;
    #$footer =~ s/\|\s*$//o;

It satisfies my requirements, but I was wondering if there was a way to have the footer keep the &percent, &quot and &dollar characters (escaped) rather than the

&percent ...
way of specifying. Then I can even have managers write their formulas smile Of course, I want to make sure that no one processes anything in the footer string till I output it. Someone else could have a case where they want to have other variables processed before it reaches EditTablePlugin. This should work for that mode.

-- KiranBondalapati - 19 Jan 2004

Ah, I see what you want - duh me!

As for the footer, I didn't clue into this as the presence of a "footer" is not documented in the EditTablePlugin documentation - perhaps because nothing is actually done with it??

Should your patch be rolled into the main EditTablePlugin distribution and the code rev'd? I see no issue with doing this as long as the patch does not break something else.

-- SteveRJones - 20 Jan 2004

I am posting the diff, if that is enough. The original is from the EditTablePlugin.pm home page for line number reference.

231,241d230
<                 #kiran
<                 if (!$doEdit) {
<                     if ($footer) {
<                         $footer =~ s/\"/\"/gos;   # expand double quote
<                         $footer =~ s/\&dollar/\$/gos;   # expand double quote
<                         $footer =~ s/\&percent/\%/gos;   # expand double quote
<                         
<                         $result .= $footer . "\n";
<                     }
<                 }
<                 #kiran
399,402c388,389
<     #kiran
<     #$footer =~ s/^\s*\|//o;
<     #$footer =~ s/\|\s*$//o;
<     #kiran
---
>     $footer =~ s/^\s*\|//o;
>     $footer =~ s/\|\s*$//o;

-- KiranBondalapati - 21 Jan 2004

Kiran, would it be possible to provide a .diff or .patch file of your changes and upload them to this area? Part of your patch might also include the syntax and an example of how "footer" now works, and the exact version of SpreadSheetPlugin that your patch goes against.

-- SteveRJones - 23 Jan 2004

Does anyone see an advantage to having a field that in VIEW mode shows only "stars" but in EDIT mode the editor can see the actual values? I've got some people who wish to keep data in a spreadsheet field that is obfuscated during viewing (clearly NOT protected!) but editable by the right party, editing controlled through the ALLOWTOPICCHANGE control. I see something like a format "hidden" that works like the password entry field definition. I've looked at the source but I am still a neophyte.

-- SteveRJones - 26 Jan 2004

  1. How can I prevent that %ATTACHURL% is expanded when I edit the table?
  2. 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

I am currently working on an upgrade, it will be released soon. New features:

  • Header cells can be placed anywhere in a table, they are treated as labels (read-only) when editing a table -- done
  • Possible do define the edit type per cell with syntax | visible text %EDITCELL{text,30}% |, editcell type can be any of the types available in format="". This is useful for web apps where you need complete control over table edits -- done
  • Possible to place "Edit table" button in any cell instead of default location below the table -- done
  • Possible to use button image instead of "Edit table" button -- done

With these features it is not necessary to escape spreadsheet formulae in the footer as Kirin proposed

To Arthur:

  1. The expansion of variables in edit cells is a documented limitation of this Plugin. Needs to be fixed.
  2. Sounds like an additional feature of this Plugin. Possibly with a hidebutton="nopermission" parameter (other ideas?)

-- PeterThoeny - 13 Feb 2004

So, Peter, at the risk of being redundant will the update do the following:

  1. Allow for a non-editable footer? (Maybe the assumption is that a footer is merely a special case of a header?)
    • Yes, declare each footer cell a label or make it a table heading (but add/remove row is not yet aware of footer row) -- PTh
  2. A fix for the %STARTINCLUDE%%STOPINCLUDE% that I pointed out way above? (unless this isn't a bug but merely a problem with my site)
  3. Keying off of Franz's request, the following observations on my part in terms of enhancements would be:
    1. If one changes the format of the header=" " and format=" " specifier can an existing table be modified to match the new header/format? The plugin currently creates new columns when header/format change, but can it also be updated to delete? As a realworld example, we have created editable tables, filled them, only to discover that we need to remove some fields. Usually these far right columns. Nothing fancy or overly intelligent - possibly starting from the far right and working left?
    2. The editing of cell contents may be restricted by specifying a TWiki group as a special instance of a cell property. If the editor is not part of "Group" then the cell is rendered as a label.

-- SteveRJones - 13 Feb 2004

I basically finished above mentioned enhancements. Needs some more testing before release.

-- PeterThoeny - 14 Feb 2004

There is a bug with this plugin when you try to rename/delete a page. On the Rename page is a listing of all pages to be renamed, with a title and a topic summary. If in this summary is an EDITTABLE present, the Rename page gets messed up. This is a screenshot of the rename page with EditTable plugin disabled:

rename.jpg

And this a screenshot of the rename page with EditTable plugin enabled. See the added "Edit table" button. The submit button is out of order now.

renamemessedup.jpg

  • I can't reproduce this. Possibly fixed already? -- PeterThoeny - 16 Sep 2004

-- ArthurClemens - 18 Feb 2004

From examining the apache's 'error_log'. The current distribution seems to be missing /pub/TWiki/EditTablePlugin/menuarrow.gif. This gif is loaded through /pub/TWiki/EditTablePlugin/calendar-system.css.

You can find 'menuarrow.gif' in 'jscalendar-0.9.6.zip' as distributed by Mishoo. (Do not know if it used to be included in earlier distributions)

  • Added missing gif images reported by Hans -- PeterThoeny - 28 Feb 2004

-- HansPype - 26 Feb 2004

Peter, the released version doesn't appear to be in CVS?

-- CrawfordCurrie - 29 Feb 2004

Just installed the new EditTablePlugin version and my apache error log gives me the following new errors when I edit a table:

  • [Mon Mar 1 14:37:48 2004] viewauth: Use of uninitialized value in numeric lt (<) at /home/httpd/twiki/lib/TWiki/Plugins/EditTablePlugin.pm line 590.
  • [Mon Mar 1 14:39:29 2004] viewauth: Use of uninitialized value in concatenation (.) or string at /home/httpd/twiki/lib/TWiki.pm line 1833.
  • [Mon Mar 1 14:39:29 2004] viewauth: Use of uninitialized value in concatenation (.) or string at /home/httpd/twiki/lib/TWiki.pm line 1834.

I'm using the 01 Feb 2003 release build of TWiki.

-- SteveRosenthal 01 Mar 2004

Probably a bug, not related to current release being discussed. Suppose I have two tables (with EDITTABLEs) visible in topic (topic 1). First visible table is through an INCLUDE from another topic (topic 2).

When you edit second visible table (i.e. the one defined in topic 1 itself), it ends up replacing the INCLUDEd table as well.

Examples can be seen at IncludedTableTestForEditTable - try editing table marked "table 1". Note that "table 2" comes from IncludedTableTestForEditTable2.

I'll assume this was in response to my post: I've definitely run into the specific case you're describing. I'm creating topics and templates with multiple edit tables in them using the RecursiveRenderPlugin, so I'm probably running into a variant of the INCLUDE issue. -- SR

-- VinodKulkarni - 18 Mar 2004

Forgive me if I'm wrong, but AFAICT this plugin has not been checked into CVS for a very long time. Shouldn't we be removing the "Developer Version in CVS" flag for plugins in this state? Where the revision controlled version is such a long way behind the release?

-- CrawfordCurrie - 18 Mar 2004

I have an unusual problem. I've setup the latest EditTablePlugin and it works fine, except when I try and add the eight row. Up to seven rows no problem, but when I try and add the eight row it hangs. I checked the active processes and it's trying to it's 'viewauth' that's hanging. When I do and strace on it I see it's trying to do a write statement.

To check things out a bit more, I manually created a table with more than seven rows and then tried to edit it. Same problem - 'viewauth' hangs.

Any idea what I should look at?

EDIT: Looks like this might only happen when I have a drop down list in the table. I've made a bigger table without the dropdown list. I'm just not sure what I should be trying to check out.

EDIT: I entered this as a support question as well - EditTablePluginHangsOver7rows. It'd be really cool if this worked well.

-- PeterWhiting - 20 Mar 2004

Maybe I'm being overly dense, but even though the text here seem to indicate that footers "work" the only thing that works is that I make then un-editable. However, when using the SpreadSheetPlugin to caluclate totals for rows, etc. I really want that footer row to stay at the end. Right now if I add a row it gets placed after the footer row that is supposed to calculate the totals.

I'm not very good at perl so I got a bit lost trying this myself. 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

non-maintainer update updated cvs to match released zip version, which was ahead of the cvs version Internal plugin version: 02 Mar 2004, Zip version: 1.19 (http://twiki.org/cgi-bin/viewfile/Plugins/EditTablePlugin?rev=1.19&filename=EditTablePlugin.zip)

-- MattWilkie - 02 Apr 2004

A rather mundane request: Could we please replace the actual table in the topic EditTablePlugin with a mockup (e.g., just copy the rendered HTML rather than use the variable rendering the table). Everytime somebody is trying out the table the topic is updated and a notice is generated that the topic has been changed. I am so tired of checking only to find out that somebody has been playing around...

-- ThomasWeigert - 16 Apr 2004

Important Bug If you have a page with a EDITTABLE table at the end, you can't save it. This has caught a lot of people ou!

-- CrawfordCurrie - 21 Mar 2004

This only happens if there is only one line return at the end. More than one and it saves.

-- SamHasler - 22 Mar 2004

This is
a table
that blocks
saves oh dear
Edit the topic, remove this sentence, and try and save and you'll see what I mean.

-- CrawfordCurrie - 21 Mar 2004

This is listed as a ALERT! Bug in the Known Issues section in the Plugin topic.

  • And is fixed as of 01 Aug 2004 -- PeterThoeny - 02 Aug 2004

-- PeterThoeny - 21 Apr 2004

Moved some requests to the wishlist at the top of topic and added two more.

-- SamHasler - 22 Apr 2004

Uploaded edittable.patch. This patch fixes the issue with getting an error when trying to edit a long table with select fields in it. It also has fixes for an issue I had with the css files not being loaded, and an addation to allow the selection of a different theme. And lastly it has a change to use jscalendar 0.9.6 which moves the language files to a "lang" subdirectory.

  • Thanks David. I can only take part of the patch since removing the expandCommonVariables will break existing functionality (SEARCH and other vars will not expand); also, when I packaged jscalendar I moved the files in the lang directory to the Plugins attachment directory and fixed the links to the lang files. -- PTh

-- DavidSmith - 27 Apr 2004

Ok, I finally I needed a feature I've added to the wishlist enough to motivate me to dig into the code and add it myself. From the wishlist:

"Values for select list items ie format=| select, 1, op1 value:op1 display, op2 value:op2 display, op3 |" would appear in form as <OPTION VALUE="op1 value">op1 display</OPTION><OPTION VALUE="op2 value">op2 display</OPTION><OPTION>op3</OPTION> "

Patch removed. See comments below and attachment.

-- SamHasler - 28 Apr 2004

Thanks Sam, I will take this into the Plugin (correcting it to proper XHTML)

-- PeterThoeny - 29 Apr 2004

Great! Although you can see I was only copying the format it was already outputting so any XHTML errors weren't mine (I hope).

I should also be posting a fix today for a bug I've found with the plugin:

I have experienced repeated edits reverting to a cached version of the table. The link for editing the table is of the form #edittable1. I think it should have ?t=datetime appended to it in the same way as the edit link.

Update: Well the time in the link might be a good idea but it appears that caching wasn't the cause of the problem. I'm experiencing select boxes reverting to the first entry when editing instead of selecting the entry from the table. This may be due to the code I added in the patch above. More latter...

Update: Yeah my code is bad. if( $valExpansed eq $expansedValue ) { needs to take account of $val/$valdis. I've looked at the code but I don't get what is happening with $bitsExpansed, my perl isn't up to scratch.

-- SamHasler - 29 Apr 2004

Ok, I've uploaded a patch that fixes the problem and also adds the ?t=datetime in the edit url.

  • Sam, the EditTable_selectvals.patch adds the timestamp to the URL. Two issues with that: Netscape does not scroll to the table (probably due to incorrect parameter/anchor sequence); it adds the timestamp also to the view URL after a save. -- PeterThoeny - 17 Sep 2004

-- SamHasler - 29 Apr 2004

non-maintainer update synchronized cvs with released zip version, which was ahead. Internal plugin version: 07 Apr 2004. Zip version: 1.20

-- MattWilkie - 06 May 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch EditTablePlugin-cn.patch r2 r1 manage 0.9 K 2002-06-19 - 04:03 ColasNahaboo allow %-vars in included parameters (v2)
Unknown file formatpatch EditTablePlugin-quietsave.patch r1 manage 3.3 K 2003-06-12 - 14:09 ColasNahaboo adds a Quietsave button to save w/o notification
Unknown file formatpatch EditTablePlugin.12Apr2003.patch r1 manage 5.8 K 2003-05-06 - 17:26 ColasNahaboo cumulative patch to 12 Apr 2003 state
Unknown file formatdiff EditTablePlugin.diff r1 manage 0.6 K 2002-05-25 - 20:58 AndreaSterbini patch implementing the off format option
Perl source code filepm EditTablePlugin.pm r1 manage 27.9 K 2003-06-12 - 14:15 ColasNahaboo Current version of 12 Jun 2003
Unknown file formatpatch EditTablePluginDefaultChangeRows.patch r1 manage 0.4 K 2003-05-04 - 07:45 MartinCleaver Defaults changes=on. Use changes="" to disable.
Unknown file formatpatch EditTablePluginExpanseVars.patch r1 manage 2.2 K 2003-04-08 - 14:47 ColasNahaboo patch to 08 Nov 2002 version: allow %vars in ops
Unknown file formatpatch EditTablePluginExpanseVars2.patch r1 manage 1.1 K 2003-09-18 - 12:03 ColasNahaboo fix for %-vars when add/del rows
Unknown file formatpatch EditTablePluginExpanseVars3.patch r1 manage 2.0 K 2003-10-13 - 22:38 ColasNahaboo fix to .2patch
Unknown file formatpatch EditTablePluginGreyOddRows.patch r1 manage 1.5 K 2003-04-08 - 15:23 ColasNahaboo greys odd rows (style)
Unknown file formatdiff EditTablePluginLineBreaks.diff r1 manage 1.9 K 2003-02-26 - 11:55 JohannesMartin Diffs to allow line breaks in text areas
Unknown file formatdiff EditTablePluginTextArea.diff r1 manage 1.9 K 2003-02-25 - 14:39 ClausBrod Diffs for textarea extension
Unknown file formatdiff EditTablePluginTextAreaDoc.diff r1 manage 3.3 K 2003-04-08 - 17:00 ColasNahaboo patch to the doc topic for the textarea patch
JPEGjpg rename.jpg r1 manage 30.5 K 2004-02-18 - 10:30 ArthurClemens Rename page with EditTablePlugin disabled
JPEGjpg renamemessedup.jpg r1 manage 34.0 K 2004-02-18 - 10:31 ArthurClemens Rename page with EditTablePlugin enabled
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2006-10-06 - 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.