Tags:
create new tag
, view all tags

Feature Proposal: EditTablerowPlugin As Default Plugin

Motivation

This topic is opened as a refactoring from the EdinburghReleaseMeeting2006x09x18 by KennethLavrsen assisting ThomasWeigert. The refactoring was done to ensure that the proposal would be considered and not ignored. Even if KennethLavrsen does not agree with the proposal as it is put forward. See discussion below.

Description and Documentation

On the topic of what Plugins to include in Edinburgh... I would suggest that we swap out EditTablerowPlugin for EditTablePlugin. The latter works well only for the smallest of tables (both with respect to rows and columns), and both have similar shortcomings when it comes to support complex tables with merged cells. The additional flexibility of inserting rows anywhere, deleting arbitrary rows, etc. in addition to the performance and usability improvements make the EditTablerowPlugin the clear winner.

-- ThomasWeigert - 19 Sep 2006

Impact and Available Solutions

Implementation

-- Contributors: ThomasWeigert , KennethLavrsen

Discussion

I hope it is OK that I picked up this one Thomas because even if I do not agree with the proposal exactly as it is suggested I agree with the background of the proposal and the problem the proposal tries to resolve.

EditTablePlugin is one of the most popular plugins and most used plugins - at least in those TWikis I manage. Just removing it would reduce it to a normal plugin with less guarantee that it is always up to date. An admin that does an upgrade from 4.0 to 4.1 by doing a scratch installation and copying the data and pub directories will find that many topics no longer works and that he has to install the EditTablePlugin. We cannot just remove such an essential plugin.

When TWiki 4 was released I used EditTablerowPlugin a few places on my Motion TWiki as a trial and had not yet installed it on the Copenhagen Motorola TWiki because I was not satisfied with the way it worked (too difficult to use - see below). And I was happy I had not because as you know it took many many months before it was fixed and worked again. An essential plugin like EditTablePlugin cannot just be removed and reduced to a normal "ranked" plugin.

That would be totally against the TWikiMission to do something that breaks backwards compatibility in this scale.

But that does not prevent us from moving in the direction you suggest! We just need to do it the right way.

EditTablerowPlugin is great. You are right in your evaluation that EditTablerowPlugin is both faster in performance and in use (one row at a time) and the need for being able to add and delete arbitrary rows is a major miss in EditTablePlugin. There are actually some contributions for EditTablePlugin that does part of this which have never been integrated. See EditTablePluginDev.

I just tried for the fun of it to replace %EDITTABLE with %EDITTABLEROW a few places and the EditTablerowPlugin is not a drop in replacement that would be compatible by just letting it recognice EDITTABLE same as EDITTABLEROW.

The feasible way to move this forward could be.

  • Create a table plugin which is 100% backwards compatible with the current EditTablePlugin. Ie. you should be able to remove the current EditTablePlugin, install the new and you would have the same features as with the old. It is OK to have additional features and different presentation (style) but the %EDITTABLE tag and all the options must work the same way.
  • Create the table plugin so that it has the additional features of EditTablerowPlugin.
  • Create the table plugin so that it has the performance of the EditTablerowPlugin.

And that again can be either a new plugin, or an enhancement to the existing.

Those would be the minimum requirements to replace the EditTablePlugin. An alternative that I would support is to ALSO include EditTablerowPlugin and keep EditTablePlugin. But for performance reasons and usability reasons I would much prefer a new plugin that appears to be an extension to EditTable to the user (less of a learning curve for existing users). ´

But if there is no commitment to do merge the plugins in a backwards compatible way, just adding it as a default plugin would make me more confortable adding it in production TWikis because I would be more sure that I would not end up with an essential non-working plugin after next TWiki upgrade. But adding it as a default must be followed by a commitment to keep it up to date. The quality bar is higher for default plugins than for normal plugins. Ie. if the default plugins do not work after changes in the core they hold back a release of TWiki until they are fixed.

An additional wish.

With respect to EditTablerowPlugin, I personally wish that it was possible to define the form for the row in the topic itself instead of having to create an additional topic for the form definition. This is why I never installed the plugin at the Copenhagen Motorola TWiki back when we were using Cairo. But I would not want to loose the possibility either. If I need to use the same table format in many topics having the format defined in a form topic is great. But when you make a one-of edittable which we often do on my TWikis it is a pain being forced to create an additional form topic.

-- KennethLavrsen - 20 Sep 2006

Hm, so basically you propose (a) to merge EditTablePlugin and EditTablerowPlugin. And (b) keep shipping EditTablePlugin with TWiki because (b1) you don't want to make upgrading even more complicated and (b2) you want to grant that EditTablePlugin remains maintained.

While (a) is totally sensible, even deprecating one or the other plugin might be desirable too for a couple of reasons.

I don't agree with (b) even though (b1) hits a point. But upgrading is a big hassle anyway where other issues are much more of a concern than installing extra gear.

(b2) is totally off. Forcing plugins to be shipped with the standard TWiki distro is no valid means to grant plugins to be maintained over time. There are lots of plugins out there that are maintained even better because their release cycles are not bound to sync with TWiki's. Telling your customers that they have to download the latest EditTablePlugin and replace the default one with it is bad. Therefore I argue to do just the opposite and remove extra plugins from the default TWiki distro as installing them afterwards will be much much easier in TWiki-4.1 anyway thanks to CDot's newest configure work.

-- MichaelDaum - 20 Sep 2006

As a general statement - not only relevant to this plugin - I want to ensure that when TWiki is released there are a certain number of essential plugins that must work. And if they do not - this will block a TWiki release. If the plugins are distributed or not is not the essential point for me.

-- KennethLavrsen - 20 Sep 2006

Well, we know that there must be good reasons to block a TWiki release. If it breaks a plugin in a way that things can only be fixed in the core then I agree with you. Otherwise you will have to keep an eye on the plugins most important on your installs and step on the maintainer's toes if available and otherwise take over plugin maintenance. Infact it is quite an advantage that plugins can be released independent of the core and we should benefit from that instead. The logical consequence of this is to remove plugins from core, externalize non-essential features into plugins and make it more of a micro kernel.

-- MichaelDaum - 20 Sep 2006

We actually do update the default plugins independent from the core today.

-- KennethLavrsen - 20 Sep 2006

Ken, I realize that there are a huge number of topics that use EditTablePlugin, so the suggestion was somewhat tongue in cheek.

But now to your suggestion of drop a drop in replacement...

I actually spent quite some time deciding on the tag for EditTablerowPlugin. I did want originally to make it totally compatible with the EditTablePlugin, but decided in the end against it.

Here is a reconstruction of the reasons, whether they are good reasons is another story...

  1. I found embedding the table definition in the table itself awkward and disruptive to the flow of the topic,
  2. I wanted to use the notation of TWikiForms which is used in many other places to define table-like things (e.g., a number of plugins). This allowed both to reuse a form for a table definition and for a form definition or other things, and it did not require the user to learn several different syntaxes to accomplish the same thing.
  3. I guess I could have used the attribute include rather than template to at least leave the topic unchanged.

So what to do? It is easy to add include as an alternative attribute. I could even see extending the inline definition to allow the style of EditTablePlugin. But I would find it not a good idea to change the template definition to use the non-standard syntax from EditTablePlugin. If really needed we could use that as an alternative definition, e.g., if include is used, use the EditTablePlugin syntax (include an inline definition), otherwise use a form template?

I just find EditTablePlugin only usable in very small tables, both horizontally and vertically. It is hardly (if at all) used on our system.

As an aside, I have also tried spawning of another browser when editing a page, but the lack of being able to force the original page to refresh (at least I don't know how to do that) makes that somewhat awkward (you are seeing an outdated table upon return) so I took it out again.

-- ThomasWeigert - 20 Sep 2006

My biggest pet-pieve here is that EditTablePlugin defines textarea fields by row x column, while TWikiForms define textarea fields by column x row.

Backwards compatible or not, that is just crazy...

-- ThomasWeigert - 21 Sep 2006

OK... I took up Ken's challenge above (well, maybe I was just procrastinating and avoiding doing something else...). Either way, I implemented the ability to parse tables defined in the EditTablePlugin syntax.

However, so as that I could reuse the form mechanisms from TWiki.Forms, I extended TWiki::Form::new by a parameter that allows the field definitions to be passed into the creator function. I generate the field definitions from the header and format fields, and then continue on with the form processing.

I can put this into the EditTablerowPlugin code with some more testing, but don't expect me to work around the change to TWiki::Form::new as this would mean duplicating lots of code. Plus, this extension may come in handy for other things also.

-- ThomasWeigert - 21 Sep 2006

Checked in a merged version. But to use the EditTablePlugin compatability, you need to patch Form.pm.

-- ThomasWeigert - 21 Sep 2006

Cool Thomas. Looking forward testing this in the weekend. We will need to think more about how to resolve that silly difference in row/column definition in a backwards compatible way. My intuitive engineers reaction is that X comes before Y - rows before columns. And each time I run into something different I go through a cycle of mistake. But just changing it breaks compatibility. There is always a way out with these things. It is just a matter of getting the right ideas. wink And ideas is something this project never lacked.

-- KennethLavrsen - 22 Sep 2006

Just a quick note: I fully support Kenneth's view; we need to stay compatible with all features of EditTablePlugin because this plugin is used very often in a corporate environment. Once this is reached we can actually replace EditTablePlugin with the EditTablerowPlugin code (and obsolete the latter one.)

-- PeterThoeny - 24 Sep 2006

Thomas. Can you elaborate on the %EDITCELL compatibility?

-- KennethLavrsen - 26 Sep 2006

What I mean is this: There is a tag %EDITCELL% introduced by TablePlugin which only makes sense in the context of editing a table in place (I think). There is no point for EditTablerowPlugin to support that one also, as it supports a totally different style of editing (row by row in another topic).

-- ThomasWeigert - 26 Sep 2006

I think many are using %EDITCELL. So we should be compatible also with that. It enabled special formatting definitions in single cells.

-- KennethLavrsen - 30 Sep 2006

Thomas, on EDITCELL support: This is a useful feature, for example to define tables of multiple key - value rows. If there is no plan to support the EDITCELL feature, it means that the EditTablerowPlugin cannot be used as a replacement (e.g. as a preinstalled plugin.) Please consider 100% compatibility so that we can replace the EditTablePlugin code with your code.

-- PeterThoeny - 30 Sep 2006

Peter, on EDITCELL support: I agree this is a usefull feature, but is orthogonal to the functionality of editing a row in a table. There are really three aspects of editing a table:

  1. Editing the whole table at once
  2. Editing a row in a table
  3. Editing a cell in a table
These are separate, and would normally not be applied to the same table. I can see that we would want all three aspects supported.

The EditTablerowPlugin supports only (2). The EditTablePlugin supports (1) and (3). So there are two strategies I see:

  • We could generate a monster plugin that supports all three modes of editing a table
  • We could generate a base contrib that supports table editing and then three small plugins leveraging that contrib to do each aspect of table editing.

One more thing on EDITCELL: why would I declare an EDITTABLE format on top, if all I want to edit is one particular cell? Shouldn't the format declaration be with the cell, not with the table? I can see the advantage of the latter if one would have random cells being edited all over the table, but that does not seem to be the typical usecase. Rather, one usually would edit the same cell in every row?

Actually, the EDITCELL seems to serve two purposes:

  • Allow to override the format definition of the edit table for a single cell, and
  • Allow to edit just a single cell
The former seems primarily targeted to have rotated tables (key/value pairs). This could maybe be accomplished better by rotating the table upon rendering, similar to what Crawford does in the ActionTrackerPlugin. The latter seems a rather rare use case. It is not clear how important it is if you can edit already a single row?

In summary, the EditTablerowPlugin cannot be a substitute for the EditTablePlugin, if "substitute" means "supports all functionality known from before", as it does not support (1). I guess we need to clarify what we mean by "substitute". I think all 3 dimensions could be considered useful. However, if I have to pick one dimension only, it would be (2).

Actually, I can see it supporting a single cell in a row also, but it would still mean to pop a window and edit that cell in that window. That would be good for large text cells, but seem awkward for a single select?

-- ThomasWeigert - 30 Sep 2006

I still need to test this. Is the needed core change implemented in the ~twiki4 branch on SVN or do I need to patch my SVN checkout version to test the new version of EditTablerowPlugin?

-- KennethLavrsen - 30 Sep 2006

Ken, the TWikiRelease04x00 branch on SVN is updated as discussed above, i.e., has the support for this merge (I assume that is what you mean by ~twiki4). I have been using this now in our installation.

-- ThomasWeigert - 30 Sep 2006

Thomas, there might be a missunderstanding on the EDITCELL feature: This is a subset of editing the whole table; you are still editing the whole table. EDITCELL is simply overriding the default cell type. For example, you can define a row of type select, and override one cell of that row to be of type text. The EditTablePlugin never supported single cell editing.

I think we have two coices:

  1. Enhance EditTablerowPlugin to be 100% compatible with EditTablePlugin, and replace EditTablePlugin code with EditTablerowPlugin code
  2. Keep the plugins separate

With the first option, the plugin would give a choice to edit the whole table or just a row (behaviour set in parameter of variable).

With the second option we can decide if the EditTablerowPlugin should be shipped as a default plugin in addition to the EditTablePlugin.

-- PeterThoeny - 01 Oct 2006

OK. I guess I read more power into the EDITCELL than it actually has. I have to confess I inferred this from the doco, and have never actually used it. What is the point of allowing the button to be placed in the cell if you cannot edit just that cell alone?

I guess merging for 100% compatability is a good goal, but may take more time than the next release. So maybe the best is to give an option for the user to have both. It is no big deal if we decide to not include. Personally, there are plugins that I don't have turned on but are included by default (SmiliesPlugin, WysiwygPlugin, TablePlugin, RenderListPlugin). I would prefer not getting them in the distribution, but it is not a large problem. The dilemma is that users are less likely to use something that they have to install separately, and where the process is not 100% smooth. That would argue for including as many plugins as possible. On the other hand, there is something to be said for a lean installation, which would argue for focusing on getting the plugin install process to work flawless and then let users install from twiki.org (or download alternatively).

Right now we have some awkward in between...

-- ThomasWeigert - 01 Oct 2006

I have tested the current EditTablerowPlugin replacing the EDITTABLE by EDITTABLEROW. And I cannot see any compatibility implemented.

So maybe this idea is too difficult to implement.

My wish list (and many other for sure) for EditTable is

  • Ability to edit one row at a time. I would prefer a discrete dot or arrow on the side of the table to pick a row for selection. It is not compatible that the first column suddenly becomes links.
  • Not loose the ability to edit all rows at the same time. If you need to quickly update many cells a user interface that requires click, edit, submit for every row is a major pain.
  • Need ability to add and delete arbitrary row. This could be simply by clicking the small arrow/dot to get to single row edit mode, and then you can either add new row below or above, or delete current.
  • Need the TablePlugin to not interpret TWikiVariables to static text when you edit and save. This is a major limitation to the use of the current EditTablePlugin.
  • Need the formatting of the editing of single rows to be defined by the EDITTABLE options and not require a form topic to define the format.

That is what is on my wishlist. And it may be better to try and pick some of the pending contributions on EditTablePluginDev instead of trying to merge in EditTablerowPlugin.

After Thomas has pulled this proposal from WhatIsIn04x01, I guess this discussion ends here for now and continues in EditTablePluginDev

-- KennethLavrsen - 05 Oct 2006

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2006-10-05 - KennethLavrsen
 
  • 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.