Feedback on Edit Tablerow Plugin

Some words on the current implementation... I have started this based on PeterThoeny's EditTablePlugin but replaced the editing of the whole table at once by a row-by-row form-based editing, which I took from ShawnBradford's SimpleTableEntryUsingForms. My primary goal was to improve performance when dealing with very large tables (if you have more than 30-50 rows in your table, EditTablePlugin is not very effective any longer). However, I tried to keep as much of the interface of EditTablePlugin as possible to allow for an easy transition.

The biggest differences right now are:

• The layout of the edit form is defined as in TWikiForms, rather than by referencing just another table with a format parameter.
• The format parameter is currently not supported, but I am planning to do so.

I do believe that relying on formats defined in the style of TWikiForms is much more consistent with the TWiki core than the style currently used in EditTablePlugin.

-- ThomasWeigert - 20 Mar 2005

Feature Suggestions

Open Issues

Discussion

Thomas, you turn out new Plugins at an incredible rate! Thanks for sharing!

I did some minor editing to the Plugin topic:

• One exmple had an extra br and /div tag that had a confusing effect on the PatternSkin
• I put the License under the "Plugin Info" section
• Added the Appraisal link to the "Plugin Info" table

-- PeterThoeny - 22 Mar 2005

I just installed this plugin (I've got desparate need for row-based editing: huge tables!!), but I'm getting the following error:

Undefined subroutine &TWiki::Render::getRenderedVersion called at /path/to/EditTablerowPlugin.pm line 175.

I'm running TWiki version: 01 Feb 2003, which I'm assuming is the issue? Or possibly user-error? I'm still re-reading the usage instructions to figure out what the relationship to TWikiForms is.

-- SteveRosenthal - 22 Mar 2005

Steve, you need to be running Cairo for this plugin to work. I think you can also make it work for your version (Beijing), but it will require some adjustments. for example, the function you are pointing out does not exist in your TWiki.

-- ThomasWeigert - 22 Mar 2005

Thanks. I was pretty sure this was the issue. I'm holding off on upgrading to Cairo until I have plenty of time to test and retreat (if necessary).

-- SteveRosenthal - 22 Mar 2005

Regarding your question on the relationship to forms... this plugin uses the TWikiForms mechanism to edit the table, which is not exposed through the Func API, so by necessity I am calling into parts of TWiki that are not guaranteed to be stable. I am committed to keep this plugin up to date going forward (as we are using it) but I cannot commit to keep it backwards compatible.

-- ThomasWeigert - 23 Mar 2005

I like this plugin a lot. I had just a few problems getting it to work:

• The installer complains about not being able to set the revision history on attachments and the EditTablerowPlugin.txt. This isn't a big deal and, truthfully, I didn't bother to figure out why. It would be nice to not have that happen, though.
• The installer failed to point out that I didn't have EditContrib installed.
• The installer did not set the executable bit on the scripts in bin/.

-- DavidBright - 24 Mar 2005

David, I am sorry, the installation procedure does not involve the installer. See the doco on EditTablerowPlugin. Somehow, using BuildContrib one gets this installer file, which I have not yet figured out how to make work. To install, just unzip, set the executable permissions (if needed), and install the prerequisites. I really should delete the installer from the file, as it is misleading (or make it work).

-- ThomasWeigert - 25 Mar 2005

Steve, I have redone the EditTablerowPlugin to not use EditContrib at all. Please redownload the plugin from the plugin topic. It should now also work for Beijing. I tried it on my Beijing release and it worked, but we went through this a couple of times already :-). Please try again. (I am so sorry, I uploaded an old file yesterday.)

-- ThomasWeigert - 27 Mar 2005

Success!

I re-downloaded and everything installed as expected and it all works! This will really help us a lot. I've got some questions about the templates, but I'll save them for another day. You deserve a break!

Thanks again!

-- SteveRosenthal - 27 Mar 2005

I'm finding that, at least with TWiki 02 Sep 2004, it's extremely sensitive to spaces in the table (actually, it's Form that is sensitive). For example:

%EDITTABLEROW{template="WarwickAllisonTestTable"}%

This	Hello	1
That	There	3

(uses WarwickAllisonTestTable)

As a quick workaround, in bin/editTableRow,

        # Work-around: Form can't handle the extra spaces.
        #              Strip them. We lose the ability to center, etc. in the table.
        #my @fields = split (/\|/, $row);
        my @fields = split (/\s*\|\s*/, $row);

-- WarwickAllison - 30 Mar 2005

Warwick, I am not quite sure what you are expecting to see here. Looking at your table above, assuming you expected that "Hello" or "There" are centered, you need to put at least two spaces around the text to be centered, as you can see from the two tables below.

This	Hello	1
That	There is something	1
There	is something else	1

This	Hello	1
That	There is something	1
There	is something else	1

This works exactly the same with or without the plugin. Maybe you are referring to the spacing for the field with the select control. There the way forms are scanned (and I believe the same is true for EditTablePlugin and its respective controls) any spacing is dropped around the select values.

Could you please explain what it is that you are seeing and what you were expecting to see? I tried your example and on my understanding it works exactly as I would expect.

I do not advise to add your patch, as this would disallow manual horizontal adjustment of table cells in text and text area fields.

-- ThomasWeigert - 31 Mar 2005

From Warwick's question I interpret the following suggestion that is added into the feature request list: "Provide for formatting of all table fields using a selection in the form, rather than the twiki table mechanism of leaving blanks to the left and right of the field content."

-- ThomasWeigert - 01 Apr 2005

Still have a bug here. I've just installed the latest version of this plugin. (TWiki Cairo, Fedora Core 3, Apache 2, not using mod_perl.) Got "Internal server error" after clicking on table's edit link, apache error log reported "premature end of script headers". Checked the scripts and found that both editTableRow and uploadTableRow had the perl location as /usr/local/bin/perl instead of the usual /usr/bin/perl. I've corrected these and now the script is running, but there's no table content to edit. Just a page header bar with a link to webhome and change form, empty page content section, and an add button in the bottom bar which, when clicked, puts a single vertical bar character at the start of the line after the table's edit button. I've tried a few things like changing the table around, no luck. Haven't seen this plugin working yet. Would be nice though

-- MarcusLeonard - 16 Apr 2005

Marcus, thanks for trying out this plugin and also for noticing the directory path mismatch. Most systems have these two directories cross-linked, so this went unnoticed for a while...

I am not sure what is happening in your second problem. Maybe you could send me the text of the topic you are trying to create, and I take a look at it.

If you want to see this plugin working, please go to this topic where I have put a couple of such editable tables with different interactions with the TablePlugin.

-- ThomasWeigert - 16 Apr 2005

Hi Thomas. As soon as I saw the raw text of one of your examples, I realised where I had gone wrong. I assumed an EditTablerowPlugin table was a "normal" table (but with per-row table editing) - I didn't realise I had to define a template as well. I went back and checked EditTablerowPlugin, and (of course) it does explain how the template works. I think I just assumed it was optional.

Maybe EditTablerowPlugin should mention that you must define a template or it won't work. Something like (under the "Initial values" heading), "You must create template topic for the table. Table cells are given initial values taken from the template, when a table row is added. Maybe even change the "Initial values" heading to "Table template topic" or something like that.

Anyway, it's all good now. This plugin is going to really improve working with large tables. Cheers, and thanks for the quick response.

-- MarcusLeonard - 17 Apr 2005

Thanks, that is a good suggestion. I'll add that to the doco...

-- ThomasWeigert - 17 Apr 2005

Hm. It seems to break %TOC%. Just shows TOC: No TOC in "Sandbox.TestTopic1" . Can't find any other reports of this problem so far. Is it just me?

-- MarcusLeonard - 20 Apr 2005

I've got a topic with headings at levels 1, 2 and 3. I pasted one of your example tables to demo the plugin ("Table with two Header Rows and Footer Row") (and created the template topic) and the EDITTABLEROW line as follows:

%EDITTABLEROW{ show="on" changerows="on" template="TableRowTemplate" format="| text, 10, init | select, 1, , C, X | text, 20, init | text, 10, init | text, 10, init | text, 20, init |" }% 

and then get the TOC error mentioned above. If I the plugin with %!EDITTABLEROW... the TOC starts working again. Any ideas?

-- MarcusLeonard - 21 Apr 2005

Fixed and updated the plugin. I had fixed a bug in TWiki (see TemplateFieldsCannotAlwaysBeRendered) as I thought it was a problem with this plugin, but that "fix" disabled %TOC% inadvertently. Deleted the improper fix. (As a side effect, the images on the EditTablerowPlugin are not quite accurate, as they should not show the smilies rendered, but this is true for all tables.) See demo.

-- ThomasWeigert - 22 Apr 2005

Excellent, Thomas. %TOC% now working nicely. In its "normal" state, my table is not rendering the smilies text into graphics, but on the update page (ie changing table row data) the smilies show up as graphics - but this behaviour is definitely not a big deal. Muchas thanks for the fix.

-- MarcusLeonard - 23 Apr 2005

Yes. Regarding the smilies, it turns out that there is a problem with forms and variables that must have spaces around them (see TemplateFieldsCannotAlwaysBeRendered). So when you use a smiley in a radio field of a form, it will be inserted into the table adjacent to the vertical bars, and the renderer will not pick it up. You will see the same behavior if you use EditTablePlugin and also in the TWikiForms.

However, in the edit the rendering is slightly different and catches the form data. Note that the TOC cannot be done correctly in the edit window as the page is split in multiple pieces before the rendering.

-- ThomasWeigert - 23 Apr 2005

I am testing the plugin. My Apache log gets filled with these warnings. I use Cairo 30-Oct-2004 version.

editTableRow: Scalar value @sections[$tableNr] better written as $sections[$tableNr] at /usr/local/apache2/twiki/bin/editTableRow line 109.
editTableRow: Scalar value @rows[$rowNr + $rowidx] better written as $rows[$rowNr + $rowidx] at /usr/local/apache2/twiki/bin/editTableRow line 137.
editTableRow: Scalar value @fields[$idx] better written as $fields[$idx] at /usr/local/apache2/twiki/bin/editTableRow line 147.
editTableRow: Scalar value @sections[$tableNr] better written as $sections[$tableNr] at /usr/local/apache2/twiki/bin/editTableRow line 109.
editTableRow: Scalar value @rows[$rowNr + $rowidx] better written as $rows[$rowNr + $rowidx] at /usr/local/apache2/twiki/bin/editTableRow line 137.
editTableRow: Scalar value @fields[$idx] better written as $fields[$idx] at /usr/local/apache2/twiki/bin/editTableRow line 147.

-- KennethLavrsen - 06 Jun 2005

checked .zip into CVS

-- WillNorris - 27 Jun 2005

I have been testing this plugin for a while and would like to put it in production. But the amount of messages on my Apache error log from this plugin is so massive that I am holding back. The perl code generates so many warnings. Is this plugin going to be fixed soon? I have looked at the code myself but I have not enough Perl skills yet to fix them.

-- KennethLavrsen - 30 Jun 2005

Kenneth, I have gone through the code and removed the warning messages you describe above (and similar).

There are still warning messages in the log as follows:

1. Use of uninitialized value in concatenation (.) or string at /.../EditTablerowPlugin.pm line 320.
2. Use of uninitialized value in pattern match (m//) at /.../EditTablerowPlugin.pm line 215.
3. Use of uninitialized value in concatenation (.) or string at /.../EditTablerowPlugin.pm line 336.
4. editTableRow: "my" variable $finalTerm masks earlier declaration in same scope at /.../TablePlugin.pm line 915

(1) and (3) could be avoided by making a check whether the particular variable is defined, but this just adds time. Most other code does not make these checks either, as you can see from the many similar messages in the log. (2) is a mystery to me as there is no variable in the mentioned pattern match. (4) is really an issue in TablePlugin.

I have updated the plugin...

-- ThomasWeigert - 30 Jun 2005

It would be incredible if this plugin let you edit the field values of forms on other topics - i.e. if instead of editing a table stored in the local topic, it would let you edit the results of a FormattedSearch, where every row in the results corresponds to another topic which has the relevant form attached.

As witnessed by this plugin's inception, there is so much synergy between tables and forms, the question is which you should use in any given circumstance. The ideal answer would be "it doesn't matter" - so that changes are gatewayed in both directions; hence my proposal above.

Of course, the implementation may not be trivial. You'd have to deal with locking properly, for instance.

-- AdamSpiers - 04 Jul 2005

Adam, what you suggest is doable, but lots of work. Also, it is mainly an extension to %SEARCH%, not to this plugin. I would suggest that you raise a feature request in the Codev web.

-- ThomasWeigert - 04 Jul 2005

Thomas. I still see this plugin as not fit for production.

I have a test page on my test server. It is a table approx. the size of the table we wanted to use the plugin with.

ONE VIEW of the page followed by ONE EDIT of ONE ROW and I have 106 errors in the apache error log adding up to 42 kbytes of junk data. Worst of all it makes it impossible to see real errors in the error log. With the traffic we expect to have it will be megabytes per day per page.

And it is exactly the error you mention.

[Tue Jul 05 16:44:55 2005] [error] [client 145.18.1.185] [Tue Jul  5 16:44:55 2005] view: Use of uninitialized value in concatenation (.) or string at /var/www/twikiexp/lib/TWiki/Plugins/EditTablerowPlugin.pm line 320., referer: http://145.18.3.55/twikiexp/bin/editTableRow/Sandbox/EditTablePluginTest?t=1120574627&template=EditTablePluginTestForm&helptopic=&tablename=1&sec=4&changerows=on&showtable=

It may take time checking for the value but I am sure writing one error line for each row in a table each time you view a page using the plugin takes much longer time. Writing to the error log is not for free.

I have looked at the plugin code and it is $scriptSuffix which is not initialized. I guess this is for those installations where scripts must be called .pl etc. I will try and figure out how to check for this in an efficient way. It cannot be that difficult. I have tried to misspell the variable name and this does not change the error message. If I remove the $scriptSuffix from line 320 the script works and I get no error messages at all.

Update

With the kind help from Crawford on the TWiki IRC the fix for the many errors is found.

In line 320 replace this line

my $eurl = TWiki::Func::getScriptUrlPath() . "/editTableRow$scriptSuffix/$web/$topic";

by this line

my $eurl = TWiki::Func::getScriptUrlPath() . "/editTableRow$TWiki::scriptSuffix/$web/$topic";

Then the plugin works and it not giving more errors in the error_log.

-- KennethLavrsen - 05 Jul 2005

Kenneth, thanks. I updated the plugin based on your suggestion.

-- ThomasWeigert - 09 Jul 2005

Hmmm.... I'm still having the problem. I got the plugin on July 29th. I checked the code & found that your described change is in place. I don't really care about that, but I thought it might be related to my table sorting issue... I've got 8 columns. When I try to sort by any of them, the table gets screwy. Some cells are blank, some cells have the wrong data, etc.

-- RoyLeach - 08 Aug 2005

Roy, thanks for sending your test input. You have found a defect in TWiki core. I believe it has to do with the spans in some of the columns. The sorting algorithm apparently is not able to handle these. I filed a bug report: TableSortingMessedUp.

-- ThomasWeigert - 10 Aug 2005

I have found a patch that solves the TableSortingMessedUp problem. It is included also in the DakarRelease.

-- ThomasWeigert - 08 Sep 2005

I realized that no one has commented on this so far, but is there a way to use a search or include for a large list in a SELECT (drop down menu) field? Lets say I have about 200 equipment items that I want to choose from. I would like to keep it on a seperate topic.

-- JeffPelton - 08 Sep 2005

Take a look at ControlsPlugin. That plugin creates an input (select, checkbox, etc.) that can be used to define HTML forms from possible values defined in a topic.

-- ThomasWeigert - 08 Sep 2005

Hey Thomas! I�m running into an issue with commas in my template for EditTableRow. The Bug/Issue value is truncated after the first comma. I end up with: %CALC{"$SET(ISSUENUM as the value.

Also, I find that the username isn�t being filled in with a value. Instead it�s filled in with �Main.guest� The web page supplied with EditRowTable says �Variables like https://twiki.org/p/pub/Plugins/EditTablerowPluginDev get expanded unless they are in a label� and since User is a text field, I�d expect it to get expanded.

Here is my template:

|*Name*|*Type*|*Size*|*Values*|*Tooltip message*|
| Bug/Issue# | label | 100 | %CALC{"$SET(ISSUENUM,%SERVERTIME{$YEAR$MO$DAY$HOUR$MIN$SEC}%)"}% %CALC{$IF($GET(ISSUENUM)>10000,$GET(ISSUENUM),[[http://superserver/bugzilla/show_bug.cgi?id=$GET(ISSUENUM)][$GET(ISSUENUM)]])}% | |
|User| text | 16 | Main.%USERNAME% | |
|Status| select | 1 | Need to Investigate, Investigating, Fix in Progress, Fixed, Will Not Fix, Not an issue | |
|Brief Description | textarea | 60x2| | |
|Details | label | 8 |  [[%CALC{$GET(ISSUENUM)}%][ Details ]] | |

-- RoyLeach - 24 Sep 2005

First the behavior you see is a result of the design of the TWikiForms mechanism. The values in the form definition are meant to be a comma separated list of literals (or a search). There was nothing built into the form handling for evaluating %CALC%.

Secondly, in TWiki forms we do not expand variables when copying from the template.

-- ThomasWeigert - 24 Sep 2005

Update: In DakarRelease, this behavior has been changd ein TWikiForms to be what you did expect: e.g., label fields are evaluated as they are, rather than being interpreted as options. Variables are being subsituted. See your example above as it appears in this screenshot from DakarRelease:

-- ThomasWeigert - 24 Sep 2005

I can't get a "date" to work on your excellent EditTablerowPlugin.

I have used the "date" format of EditTablePlugin. Your example on the web shows the inclusion of a date in a form. You don't provide the source code to identify HOW you got the dates into the form.

There is no "date" field within TwikiForms. I played around with JSCalendarContrib, and could get it to work on a web page.

I also found some banter relating to this here: http://twiki.org/cgi-bin/view/Codev/JavaScriptDatePickerForForm

I know this is likely a pretty newbie question, but how do I get the date format to work in EditTablerowPlugin ? Do I just hack my "Form.pm" ? Am I just completely missing something here ?

-- Frank Peterson

Frank, I am not sure what you are asking. Are you having trouble to have the JSCalendar edit a field in EditTablerowPlugin? In that case, you need to install JSCalendarAddOn, not the contrib to make the form use the calendar. Then just make the field of type "date". Please advise in case I misunderstood...

-- ThomasWeigert

Thank you, JSCalendarAddOn was just what I needed! This is TOO GOOD!

-- Frank Peterson

I didn't want to bug you again, so I summarize the 2 issues I have:

1. I can't seem to set the default date format with JSCALENDARDATEFORMAT.
2. I tried to copy your use SERVERTIME in the example, only I've got trouble (I am using a label - so it can't be editted - but then it actually puts in the table - so it doesn't record the current time, but just displays the actual time).
   1. Frank: try %<nop>SERVERTIME{}% in your label so that it works when saved. See EditTablePlugin"Limitations and Known Issues" and see if it works. -- MarcusLeonard - 11 Mar 2006

-- Frank Peterson

This is a very useful plugin. Thanks for sharing it. I have an issue while using the plugin though. For example, when I specify values for ALLOWWEBVIEW, ALLOWWEBCHANGE and ALLOWWEBRENAME, I am not able to get the Form to appear while trying to add/update a table. I mean the ADD / UPDATE related are present without the form. If I don't specify values for the 1 or all the 3 variables above, this plugin is functioning as expected. Please verify me whether I am missing something or is it an issue to be noted. Thank you.

-- KarthikChinnayan - 20 Oct 2005

Karthik, can you please go to here and try to edit one of the example tables. In this web there are ALLOWWEBCHANGE and ALLOWWEBRENAME set. Please see if the problem occurs there.

-- ThomasWeigert - 11 Nov 2005

Does this plugin work in DakarRelease? I'm getting this error message:

Undefined subroutine &TWiki::userToWikiName called at /export/webroot/laut/intranet/bin/editTableRow line 80.

-- RainerHenze - 22 Nov 2005

I always put a link to the TWikiForm that I use to edit the table. I don't know if anyone else would like this but I'd like an icon that would link to the form

-- WayneDahl - 08 Feb 2006

Thomas. Any chance your plugins will be upgraded to be compatible with Dakar? This plugins fails miserably in Dakar.

-- KennethLavrsen - 19 Feb 2006

Thomas: Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 20 Feb 2006

I'm slightly devestated. I can't upgrade to Dakar now because we are kinda dependant on this tool.

-- JeffPelton - 14 Mar 2006

plugin updated to run on TWiki-4 through WikiRing.com commercial support

-- SvenDowideit - 05 Jul 2006

Will anyone be upgrading this plugin as opensource?

-- TomFenstermacher - 13 Jul 2006

?! Why not simply download it from EditTablerowPlugin? It's GPL!

-- FranzJosefSilli - 13 Jul 2006

Sorry, I should have been more clear. To the best of my understanding, it does not work with Twiki-4 (or Dakar), which is what my company is running on. I was hoping that someone has upgraded the plugin to work wtih Twiki-4.

-- TomFenstermacher - 31 Jul 2006

I had upgraded my plugin in parallel, but realized that Sven has done so also. I need to check what the differences are... I'll attach my update to this topic in the meantime...

-- ThomasWeigert - 31 Jul 2006

Hi Thomas! I have the same problem as Frank Peterson described above: I can't get a "date" to work on your excellent EditTablerowPlugin. Unfortunately I'm on a managed server (so I don't have root/shell access). Therefore I cannot apply the patch you proposed (JSCalendarAddOn). Is there any other way to make "date" work with the EditTablerowPlugin?

-- StephanMaasen - 25 Aug 2006

My updated version does include the JSCalendarContrib making unnecessary the patching to get the calendar on date fields. I will upload next week. If you are in urgent need, look at how the recent version of EditTablePlugin integrates JSCalendarContrib and emulate this.

-- ThomasWeigert - 26 Aug 2006

Thanks for your help Thomas! I'm not a programmer, so I'll rather wait for your update. One more thing I realized: when I use variables like % SERVERTIME% or % CALC% in textfields, then they are either calculated in the form already OR they are not expanded at all (neither in form nor in table). I tried "!" and "< nop>" in various combinations. Only when I use select boxes, everything works as planned. Thanks again.

-- StephanMaasen - 30 Aug 2006

Uploaded a new version which allows date type fields by linking to JSCalendarContrib. Also makes sure that %CALC% in labels gets properly expanded. Please download and install the new version of JSCalendarContrib also.

Note that this version does not include Sven's updates, which also supported Cairo installations. If you need to run on both Cairo and Dakar, please use the version attached to this topic below.

-- ThomasWeigert - 04 Sep 2006

Many thanks for all the work on this plugin. Unfortunately I'm getting the following "Access Denied" message when trying to use this plugin (on TWiki-4.0.4-2). However, I am a TWiki Administrator and am able to edit this topic.

Access check on TWiki::User=HASH(0xa99065c).AwaySchedule failed. Action "Edit topic": You are not permitted to edit this topic.

Any suggestions or help would be greatly appreciated.

-- DevinBougie - 06 Sep 2006

Devin, can you please be clearer on what you experience. How I understand your report is that you are logged in as the Admin user but you get the above error message when trying to use EditTablerowPlugin to edit?

Note that the user in your report is due to a typo in the uploaded version, which I have corrected. Can you describe the sequence of events that lead to above message?

-- ThomasWeigert - 06 Sep 2006

Thanks for the reply, Thomas. Everything you say is correct. I download the most recent EditTablerowPlugin.tgz (posted 04 Sep 2006 - 06:25) and unpack it on our server. After installing, I correct file ownership and permissions, and then enable the plugin. However, when trying to use the EditTablerowPlugin (both when editing individual rows and when using the main "Edit Table" button) I get the "Access check ..." error. Yes, the user I am logged in as is an Admin, and is able to edit the page normally. I only get the "Access check ..." error when using EditTablerowPlugin.

-- DevinBougie - 06 Sep 2006

Please try the updated version I uploaded yesterday, and let me know what happens... Please make sure you have your .htaccess files set to allow the scripts to execute...

I had only tested this against TWiki-4.0.2, so the problem may be with some change since then. I won't be able to install the latest version immediately to test myself...

-- ThomasWeigert - 06 Sep 2006

I have installed the latest TWiki from SVN and tested EditTablerowPlugin. I did not encounter the problems you describe...

-- ThomasWeigert - 07 Sep 2006

Once I installed the updated version (posted 06 Sep 2006 - 22:38), everything works great. Many thanks for the fix!

-- DevinBougie - 07 Sep 2006

Thanks for updating the Plugin and JSCalendarContrib, Thomas! I installed both and when I click on the calendar-symbol when I edit my tablerow then it simply saves the tablerow, i.e. there is no calendar popup. In the form I added "| something | date | 0 | | something |". I have the DateFieldPlugin installed also. Any ideas what I might have done wrong? Sorry, if these are stupid questions. Thanks again!

-- StephanMaasen - 13 Sep 2006

Hmmm.... Maybe there is an interaction with the DateFieldPlugin? We are using this in our organization without any problems... Do me a favor. Bring up an edit page, then right click (assuming you are on IE) and select "view source". Save as text file and send me the file, I'll see whether the generated HTML shows some problems...

Also, in a second experiment, please disable the DateFieldPlugin (in configure) and try again...

-- ThomasWeigert - 13 Sep 2006

Thanks a million! I disabled the date plugin and everything works like a charm now. My custom format of the date (%e.%m., via "set dateformat") is gone now, of course. Can someone tell me where/if I can customize the date format for the jscalendar/contrib? * EDIT: * I made it work by changing 'JSCalendarContrib dot pm'. If there's a more elegant way of doing this, I'd be happy to know. Thanks again!

-- StephanMaasen - 15 Sep 2006

Hm, aren't there JSCALENDARDATEFORMAT, JSCALENDARLANGUAGE or JSCALENDAROPTIONS settings you could reuse? IIRC one was able to specify the date format used by the EditTablePlugin with one of these settings.

-- FranzJosefSilli - 15 Sep 2006

Thanks for your suggestion, Franz-Josef, but I tried "Set JSCALENDARDATEFORMAT" and it didn't work. No big deal, really. Just thought I let you guys know.

-- StephanMaasen - 15 Sep 2006

Stephan, I cannot help you if you do not send me more detail...

-- ThomasWeigert - 21 Sep 2006

After some discussion in EditTablerowPluginAsDefaultPlugin I added a mode to be compatible with the schema definition as in EditTablePlugin. However, that feature requires a patch to Form.pm. This patch is not required if one uses the template based style of defining table schema.

-- ThomasWeigert - 21 Sep 2006

Hm, EditTablerowPlugin would have to support the EDITCELL feature of EditTablePlugin, to be a full replacement for the EditTablePlugin, right? Great work Thomas, supporting the header/format notation instead the need of a separate template topic!

-- FranzJosefSilli - 21 Sep 2006

Well, I don't know. EDITCELL seems to be a separate feature that is unrelated to table editing in general. I won't be adding that, as it is contrary to what else EditTablerowPlugin does... Also, I don't know how much that is really used...

One could to a separate plugin that supports that feature in isolation...

-- ThomasWeigert - 22 Sep 2006

Thomas, I'd like to give more details - I'm just not sure on what? Disabling the date plugin (as ypu suggested) solved my problem with your plugin. And the date format I could change by changing 'JSCalendarContrib dot pm'. I was just asking whether the latter could be done in a more elegant way, i.e. via some setting and without editing a file on the server. That's all. Again: thanks!

-- StephanMaasen - 25 Sep 2006

Stephan, I updated JSCalendarContrib to allow for configuration in your LocalSite.cfg. Please see JSCalendarContrib for details. I have also raised a change request to allow TWikiForms to be more flexible so that one can have per field settings for the calendar.

-- ThomasWeigert - 26 Sep 2006

b-e-a-u-t-i-f-u-l Thanks so much!

-- StephanMaasen - 28 Sep 2006

Feedback on bin scripts: You could try to do eliminate the editTableRow and updateTableRow scripts, e.g. do all processing in the plugin. This is possible with plugin specific URL parameters to the viewauth and/or save script, as currently done by the CommentPlugin and the EditTablePlugin. This approach makes it less likely that the plugin breaks on a TWiki upgrade. It also keeps all code in the same place, which is easier to maintain.

-- PeterThoeny - 30 Sep 2006

I've installed Cairo+Dakar version of EditTablerow plugin on my TWiki (Cairo, Windows XP with Apache 1.3 and CygWin). It works great and really solved my problems with long tables! Just wanted to draw your attention to a few small things:

• the ZIP at the bottom of this page is broken; but I successfully repaired it via WinRAR
• the latest ZIP on the EditTablerowPlugin page doesn't seem to work on Cairo; are you planning to support it in future releases?
• I miss the row field type; is there any workaround for this?
• When I click on Edit link and then press Cancel, the empty row is added to the table; is there any workaround for this?

-- AlexAgranov - 04 Oct 2006

The Cairo+Dakar version is not maintained by the plugin author. The new features that have been edit are only available to the Dakar version of EditTablerowPlugin.

I will look at your row type to be edit to EditTablerowPlugin.

-- ThomasWeigert - 04 Oct 2006

EditTableRowPlugin greatly helps edit large tables, and it's smart to picks up the TWikiForms syntax rather than introducing another field definition syntax.

One question, though: Is there a way to make EditTableRowPlugin compatible with the WYSIWYG editor? Currently WYSIWYG seems to add spaces around the pipe | separator, which messes up "select" drop-downs in EditTableRowPlugin.

E.g., if there's select drop down with values Y and N, WYSIWYG changes the raw table row from |Y|N| to | Y | N | etc, so that EditTableRowPlugin can't interpret the values anymore because it gets confused by these spaces.

Any way around this; any setting we might need to add?

Another question: The row editor has a button "Replace Form". Can this be disabled?

Thanks

-- UlfBrandes - 13 Oct 2006

On the WysiwygPlugin it is best to email Crawford. There is nothing the EditTablerowPlugin can do. Well, we could introduce blanks everywhere as well, but that would be different from how forms are handled, and I prefer not to introduce such differences.

Removing the change form on the row editor is a good idea. I will check into that...

-- ThomasWeigert - 13 Oct 2006

You could remove leading and trailing space in select values to be more forgiving with edits.

-- PeterThoeny - 14 Oct 2006

Peter, I think what Ulf bemoans is that EditTablePlugin introduces a single space around the entries in the table and the WysiwygPluging adheres to that. However, that is not how forms behave, and thus, EditTablerowPlugin does not introduce these spaces either....

-- ThomasWeigert - 15 Oct 2006

I believe check lists, radio lists and selects are immune to leading and trailing whitespace in the TWikiForms defintions. Anyway, small detail.

-- PeterThoeny - 15 Oct 2006

I'm having a little trouble getting the EditTablerowPlugin to work. I've installed, verified permissions, etc. Whether I use a TWikiForm or if I use the EditTable syntax, when it comes time to actually add the line to the table nothing actually happens.

I hit edit table, I fill out information, or I choose to edit an existing line, I then hit Add or Update, nothing happens. I am just returned to the table as it previously existed. Nothing actually gets changed or uploaded. I've tried both the zip and .tgz, just in case they were different.

I'm using TWiki 4.0.4.

-- AJAlfieriCrispin - 05 Dec 2006

Found (kind of) my answer... On a desperate whim, I tried to see if it was my skin. It seems that bin/editTableRow does not work with the skin named "quickmenu". If I switch back to skin pattern, then things work.

-- AJAlfieriCrispin - 05 Dec 2006

Thanks for finding this bug. I uplaoded a new version... There was a typo in the template for the default skin...

-- ThomasWeigert - 06 Dec 2006

Dude, thank you so much! Your turn time is incredible. Every once in a while I double check myself for deploying TWiki instead of SharePoint... I'd never get this sort of attention from Redmond. Thanks again, especially for helping cement my enthusiasm for open source. If you find yourself in San Francisco, I'll buy you a beer.

-- AJAlfieriCrispin - 06 Dec 2006

The attachment appears to be corrupt. Tried windows, linux and solaris. Could someone re-attach a good copy?

thanks

-- EricAiken - 13 Dec 2006

I just downloaded the .zip file from the plugin page, I can unzip it just fine (on Windows.) Same for .tgz. It could be a caching issue on your side.

-- PeterThoeny - 13 Dec 2006

I have a summary page the includes multiple component pages that have tables. These tables should not be editable in the summary page, so I set changerows="off" when including them (using a variable).

However, if you set changerows="off" or changerows="no" then the edit button is not shown at the bottom of the table, but edit links for existing rows are still there, which is not what I would expect.

I created a simple local patch which duplicates the "if ( $params{"changerows"} ) { ..." check of line 300 on line 342 as well. This resolves the issue for me.

Would it be possible to get this change included in the next release? Or have I gone down the wrong path on this?

Thanks.

-- KeithBurdis - 13 Dec 2006

This may be a confusing name, but changerows refers to the ability to add or delete rows to an existing tables, not to the abilty of changing existing rows. Making a table non-editable was not the goal.

-- ThomasWeigert - 13 Dec 2006

Previously I used the EditTablePlugin in the component pages. Including these pages with changerows=off does render the tables non-editible. Your EdiTablerowPlugin works much better (and my users prefer it), but I need to achieve the same effect, otherwise they try to edit the included tables and this fails.

I understand that you are trying to achieve compatibility with the EditTablePlugin, but it does not support editing individual rows directly. So, to remain compatible with EditTablePlugin would it be possible to add an additional value (changerows=none perhaps?) that makes a table completely non-editable?

-- KeithBurdis - 13 Dec 2006

Sorry to be a pain here, but I continue to get apparently corrupt downloads using different systems, networks and OS's. I believe there is a problem with the attachment. here's the md5sum I have after numerous downloads: 121abbcc71a2b6f2c844f6f9f2a67570 Could someone please verify this. Thanks. (fyi, perhaps someone could upload a tgz file.)

-- EricAiken - 13 Dec 2006

I tried downloading the EditTablerowPlugin-cairo+dakar.zip attachment on this page and also find it corrupted - with the same md5sum.

If you are running Dakar, the attachments on EditTablerowPlugin work fine.

-- KeithBurdis - 13 Dec 2006

The EditTablerowPlugin-cairo+dakar.zip is much outdated, as is Cairo. I would suggest that you transition to the more recent releases of TWiki soon. I once also made the mistake of staying too long on an old version.... the longer you wait, the more pain the upgrade is....

-- ThomasWeigert - 14 Dec 2006

Keith, will do. However, in the next version of TWiki editing of included tables will work also, as the necessary support infrastructure will be available then.

-- ThomasWeigert - 14 Dec 2006

Thanks Thomas. Please could you include the parameter in your EditHiddenTablePlugin too. TWiki just keeps getting better and better

-- KeithBurdis - 14 Dec 2006

I agree with upgrading. I've upgraded a few twiki's already, but I really could use this version of the plugin in the short term. Could you please try uploading a new version of the plugin, thanks

-- EricAiken - 14 Dec 2006

Eric, I am sorry but I do not have this version myself. This was produced, I believe, by Sven.

-- ThomasWeigert - 15 Dec 2006

There have been comments above on difficulties when ALLOW... is set. I have tested this several times and cannot observe these problems. Can somebody who is experiencing difficulties describe a test case that would exhibit the problem?

-- ThomasWeigert - 15 Dec 2006

This hasn't been tested on 4.1 yet, has it?

-- FranzJosefSilli - 29 Jan 2007

I'm also on Edinburgh (4.1.1) and getting the problem mentioned on JSCalendarContribDev with an unblessed reference. I've added renderFormFieldForEditHandler from the previous JSCalendarContrib release as it suggests there, but I'm not using a date field anyway. After some further debugging, it looks like the new TWiki::Form call is failing because it's trying to look up a template called MYWEB.Oopsleaseconflict. Using format instead of template doesn't give a form at all, but doesn't give an error either. I saw the patch for Form.pm but it won't apply cleanly.

-- CallumGibson - 23 Feb 2007

Bingo - creating a temporary directory called pub/_work_areas/EditTablerowPlugin fixed editing with a template form. The old format works if you define both header and format, but when using a textarea, it parses the rows and columns back-to-front from EditTablePlugin, so it's not really compatible.

-- CallumGibson - 23 Feb 2007

See below a patch for fixing the field parsing for textarea

-- CallumGibson - 23 Feb 2007

Noticed a couple of problems using TWiki 4.1.2.

1. The cancel link wasn't unlocking the topic appropriately. Fixed this with changes in EditTablerowPlugin-templates_editTableRow_pattern_tmpl.diff.txt attached below.
2. Problems adding or editing a row because the "template" cgi parameter is getting hosed in the middle of operations by TWiki::Func::checkTopicEditLock. Attached a diff below that gives a quick hack to fix - EditTablerowPlugin.pm-lease_conflict_TWiki4.1.2.diff.txt

-- DuncanSalada - 19 Mar 2007

Refreshed plugin from SVN as the zip was unavailable from /pub/. Plugin is still not installable afterwards using configure, reported as Bugs:Item3914.

-- SteffenPoulsen - 17 Apr 2007

As is the case with EditTablePlugin, the ability to insert a new row anywhere in the table, not just at the end, would make this a killer plugin.

-- VickiBrown - 22 Jun 2007

Hm, doesn't Crawfords EditRowPlugin (a planned replacement for the EditTablePlugin) provide exactly this feature Vicki?

-- FranzJosefGigler - 24 Jun 2007

I just installed TWiki-4.1.2, Sat, 03 Mar 2007, build 13046 and I'm getting the renderFormFieldForEditHandler problem CallumGibson described on 23 Feb 2007 above.

I've narrowed it down to the &TWiki::Func::checkTopicEditLock calls at line 503 and 506 (e.g. in the doEnableEdit sub). I'm guessing that this method thinks the topic can't be edited and then is stomping over the public $template var to set it to an oops value.

I would fix this and submit a patch but I'm not quite clear on what "should" happen here with checking for edit conflicts. If someone wants to give me a pointer I'd be happy to fix it up.

-- RobManson - 29 Jun 2007

Thomas: We replaced the JSCalendarContrib with a new DatePickerPlugin, proposal at ReplaceJSCalendarContribWithDatePickerPlugin. With this, extensions that use the JSCalendarContrib need to be updated. This is mostly done already.

You maintain the EditTablerowPlugin - the modification policy is set to "contact author first". Could you please update the plugin to use the DatePickerPlugin instead of the JSCalendarContrib? The how-to is documented at JSCalendarContrib. I can do the change for you if you wish, let me know. I also sent you an e-mail on 2012-12-16 in regards to this change request.

-- PeterThoeny - 2012-12-28