Tags:
create new tag
, view all tags

Introduction

I have been working on a way to create tables using the pre-existing form capability. What I have done was expand the current TablePlugin routines to support dynamic table creation within a page.

It all stems from the fact that the table syntax is simple and compact, but it also becomes very ugly to look at quickly for large tables.

I am not sure how to demonstrate the capability here, but I will try to explain and place my working scripts here.

The idea is that you create a form just as would normally. This allowed you to place one form per page. Now let's think of the forms as just entries into one row of a table. All your elements that are entered in will than be displayed as a nice table.

The table creation is an extension of the table format. Here is an example entry on how to embed the form based table:

Sample Empty Table Template

%TABLE{template="VerificationForm" tablename="VerificationMatrix" topic="%TOPIC%" action="on"}% 

REQID Requirement Statement Verification Statement Scenario Created Vectors Generated Hardware Matched
{ Add } Table Name: VerificationMatrix2 | Template: Test . VerificationForm

Parameter Description

  • template : the form that has been generated using the TWikiForms syntax
  • tablename : an unique table description of the table so multiple tables can use the same template
  • topic : self-explanatory (Needed inside the code, it gets lost otherwise)
  • action : used to add or remove the capability of adding to the table

Needed Files

Needed bin scripts :

  • uploadTable
  • editTable

Needed templates :

  • editTable.tmpl
  • editnewTable.tmpl

Updated lib routines :

  • /Plugins/TablePlugin.pm
  • Meta.pm (Only added TABLE tags -2 lines-)

I currently have it running on an internal web and it seems to be working correctly.

If others are interested I will try to update and fix bugs.

Updates

Bugs

  1. HTML tags in the first column have not been tested
    • Will probably produce lots-o-errors

Wish List

  1. Added Edit/Action Button to last row to facilitate editing
  2. Printing of TABLE data to file in addition to META data

Comments / Discussion

Very interesting - not sure how this compares to a FormattedSearch of the form's metadata - that can also put data into a table, extracting the data from the form data across a number of topics. This looks a lot easier, though.

-- RichardDonkin - 25 Feb 2002

I took a look at the FormattedSearch page and it seems to search for information and display it in any particular format you want including table.

This update allows you to create tables on a page. I only used the form capability as a means of inputing the data into the table. It is purely a means of creating tables. Adding or deleting elements of a table without having to edit the text of the page.

This makes editing a large and complicated table as simple as filling out a form.

-- ShawnBradford - 26 Feb 2002

A variation of this feature is the Plugins.EditTablePlugin which works in parallel to the Plugins.TablePlugin

This topic should probably be converted to one of the Plugins.AddOnPackages

-- PeterThoeny - 19 Apr 2002

I have installed this feature on our TWiki and I really like it. I just wish one thing was different: I don't like the need for the unique reference number in the first column. A table should not require a key. (Is this an artifact of how the meta data is used?) Great feature, though.

-- ThomasWeigert - 05 May 2002

I admit having to create unique names is a pain. I will definately look into coming up with a simplier approach.

I agree that each element should not need a key. The one thing I was having difficulty with is editing one row at a time. This forced me to use the first column in the table as a link to edit the row.

I would like to keep the ability to edit one row at a time. In order to keep this functionality I need to create a link to do this.

I could automatically create an additional column at the front that would contain a small icon or something ... This could automatically create a unqiue reference names based upon the date.

It can be removed if the action="off" is set.

(Note: A unique reference name is needed so that $meta fields do not clobber each other.)

It is important to me that it looks nice and tidy. Since I do not plan on setting the action on and off all the time. These table are eventually printed and presented at meetings so appearance is important to me.

It seems that I can not move the topic to the above suggested place. Would it be prudent to create a page there and start from the beginning?

-- ShawnBradford - 07 May 2002

I think the need for the unique reference is an artifact of your storing the table in metadata, as you then need to associate somehow the rows with the entries in the metadata.

You could also store the table as standard text underneath the %TABLE{...} line. Adding an edit button could bring up clickable buttons with each table row which then would get you back to the edit template, as you do it now. Alternatively, each row could have an action (edit) button on the side. This would be no different than having the action button on the attachment table, isn't it? (I realize that attachments rely on the file name to get a unique metadata reference.)

In particular in light of your comments regarding the table needing to look good I am surprised about the key field. It seems to me that you would not want to see that if you show your tables in presentations...

-- ThomasWeigert - 07 May 2002

I was having issues with the key fields also, and the action button would also be cumbersome on charts. I have worked out a solution that is very similiar to the original but makes the unique reference transparent to the user.

(I like not having the data show up in the editable page because it is nice to have have a simple clean page to edit not overloaded with table syntax, it is intimidating for a beginner to see such a page and begin to add to it. Also it removes the possibility that someone could go in and accidentally edit the table by mistake.)

In the following updates, the first column no longer needs to be unique. The uniqueness is done behind the scenes in the script. It will use a timestamp to determine the unique name. This should be adequate as long as multiple people do not edit the page at exactly the same time wanting to create a table element.

I have ran it on my side and it seems to be backward compatiable and allows multiple elements in the first column to have the same name.

I have included the updated files below. It required simple changes to the following files :

Updated bin scripts :

  • uploadTable
  • editTable

Updated templates :

  • editTable.tmpl

These modifications still create a link out of the first columns text to allow editing of the row. This seems the cleanest way to implement this, but having any HTML tags there still has not been tested.

I have also updated the TablePlugin.pm such that the file attachments are sorted properly. There is a comment on the TablePluginDev page about the modification.

-- ShawnBradford - 07 May 2002

This is great. I've installed the update and it works beautiful. I probably would prefer the action button over making the first column a link, as this will look funny if we are dealing with a larger cell (a button/action link at the end of the table is easier to ignore). Thanks so much.

-- ThomasWeigert - 07 May 2002

TablePlugin Sorting Issues

I noticed a minor interaction with the sorting of tables. I think that the table headings should show the tool tips that are defined in the form. But instead it says "Sort by this column"....

-- ThomasWeigert - 16 May 2002

The button/action link I can see as being useful. I have been trying to brainstorm on a way we can develop a more seamless transistion from presentation to editing. I have been working on a couple sites using DHTML and it seems like we might be able to utilize some of the functionality here.

Although support for this will be difficult since it is very much browser dependant.

Let me know if the link for the first column becomes unbearable, I can make it an option that is set in the action parameter that is passed to the plug-in, it should not be too difficult to implement.


I looked into the Tool Tips that you mentioned before and it does not like an easy effort to change. I have a question though. Would you still what to have some reference to sorting or just have the tool tip message in the form?

I think having the sorting reference there is important for first time users when they are not fimiliar with table plugin features.

Users can also click on the form listed at the bottom of the table to get a description of the headings.

ShawnBradford - 21 May 2002

Regarding the Tool Tips, I don't think this is crucial. I was just pointing out something I noticed.

-- ThomasWeigert - 21 May 2002

I did notice something else, though. It appears that when bringing in your TablePlugin.pm file, the original working of the table plugin is affected negatively. In particular, sorting on tables that do not use your way of doing tables does not work any more. I have started looking at why this is happening, and I have not gotten very far yet. It is not an installation error, I think, as if I replace your TablePlugin.pm file with the one from the TablePlugin, then sorting of the standard tables works (of course, your tables don't work then).

-- ThomasWeigert - 21 May 2002

Regarding the link in the first column. I would think it is nicer if it was not there but is optional. I don't know if "unbearable" is the right word, but often that column seems out of place.

-- ThomasWeigert - 21 May 2002

It seems that in my installation everything is working okay. Old and enhanced styles are rendered properly. I will update the versions of the files below to reflect my current snapshot.

There are a couple fixes that I have added that are very minor.

  • the first column was always "align=right" (fixed this)
  • Text fields did not render carriage returns properly (fixed this)

-- ShawnBradford - 21 May 2002

I have installed your recent updates into a clean (i.e., Athens TWiki) after having applied TablePlugin and EditTablePlugin. I am still getting the problem with that tables that do not use templates do not sort any more.

-- ThomasWeigert - 29 May 2002

Let see if we can figure this out.

I am assuming that without my updates everything works okay. The only two files that replace current TWiki files are Meta.pm and TablePlugin.pm all the other files are additional and should not affect any visual rendering like sorting.

Given this we can look at the Meta.pm and TablePlugin.pm a little more closely. Since the Meta.pm code only has two lines that were modified, I would rule this file out as the culprit.

I am assuming there is something in the TablePlugin.pm code that is causing the issue. After taking a closer look at the TablePlugin.pm code I have cleaned up some little things that might be causing some errors.

  1. Locally declared $template, $tableName, $action
  2. Changed $topic to $tableTopic since $topic was already being used in as a global parameter
  3. Locally declared $tableTopic

The new TablePlugin.pm is attached below. Let me know if this solves any problems.

-- ShawnBradford - 30 May 2002

This is way too weired. I addd your new Plugins/TablePlugin.pm, but it still does not work. Note that tables using your SimpleTableEntryUsingForms extensions sort fine, tables using EditTable sort fine, but the standard tables that rely only on TablePlugin do not sort.

Could you do the experiment that I have done and start with a virgin code base and then let's make exactly the same changes? We can also try to work this out offline, so we don't create this huge email trail here inline? Note that I am getting this problem both on Unix and on PC.

-- ThomasWeigert - 30 May 2002

TablePlugin Sorting Issue Fix

I finally was able to duplicate your problem. The reason I was not seeing it was because I was blind. I just didn't try to sort the normal tables. I was using the initsort in the %TABLE{}% tag and since it was sorting I assumed everything was fine. After trying to sort one of the tables I quickly saw what the problem was.

I do not want to go into any great detail, but I have fixed the problem and placed the TablePlugin.pm code below. I will refresh everything just in case.

Just a small note on sorting. It seems that you can only uniquely sort one table per page. If you try sorting another one the original goes back to its original state. The original state can be controlled by the initsort tag though.

-- ShawnBradford - 31 May 2002

You did it! Thanks.

-- ThomasWeigert - 31 May 2002

Ability to Copy rows update

I have added to ability to copy rows to the code. It seems since I made the unique reference transparent to the user I needed to add the capability to copy rows. The following files have been updated :

  • templates/editnewTable.tmpl
  • bin/updateTable

-- ShawnBradford - 03 Jun 2002

I noticed the following problem: When forgetting to enter data into the cell for the first column of a row, it becomes impossible to delete or edit this row. (Of course, one can go into the metadata to edit the row there.)

-- ThomasWeigert - 21 Jun 2002

I will begin working on a solution to this. This will entail adding something similiar to an action link to the row, similiar to what you suggested earlier. I want to try out a couple things, but I will post it when I have completed the work.

-- ShawnBradford - 26 Jun 2002

Shawn, I ran into another set of troubles... When I define a from that has a field defined to be checkbox, then anything entered into that cell is not stored in the meta data representing the row. You can easily verify this by changing the "Vectors Created" field in your example to checkbox. What I would expect is that all the checked boxes are taken as value, as in the other forms. But what happens is that the cell remains blank (with nothing stored in metadata).

-- ThomasWeigert - 19 Jul 2002

The checkbox bug has been has been fixed. The only affected file is uploadTable. I have also updated the TablePlugin.pm code to reflect Peter's latest updates.

-- ShawnBradford - 19 Jul 2002


There are a number of plugins that leverage tables, e.g., most recently FeedbackPlugin. In particular for that plugin, SimpleTableEntryUsingForms would be an ideal vehicle to have users enter tables. Unfortunately, as SimpleTableEntryUsingForms stores its tables in metadata, none of the plugins operating on tables can make use of this wonderful means of entering the table data.

I realize this would be a big change, but I really question the wisdom of using metadata to store the table rather than coming up with a scheme that would allow the tables to be stored in the normal form.

ShawnBradford, I love your plugin and my organization uses it heavily. However, I strongly encourage you to reconsider your decision of how to store the table data and investigate moving to standard tables. I believe the utility and applicability of your wonderful addon would be greatly enhanced.

-- ThomasWeigert - 22 Aug 2002

Please check out DataHandling to brainstorm the issues with storage that are raised here.

  • Sometimes you need to be able to see the tables that are being created in edit mode, so we need something that allows you to write to a certain table within a topic.
  • TWiki::Meta only supports storage of a few parameters defined by a fixed type and a unique key. For tables, it would be useful to add support for multiple rows of parameters per type/key combo.

-- WoutMertens - 25 Aug 2002

Thomas,

Sorry for the long absence.

I have been thinking about changing the storage of data from META into the text of the page, but the EditTablePlugin essentially does this. My work would only be a slight modification from the work that Peter has already done.

Some of the benefits of this plugin is that it allows a cleaner view of the page and divorces the table data from the text.

The one thing I would like to maintain with this patch is the storage of the data in another medium. Currently I use the META variables to store data. I could use a seperate page and store the data in normal text syntax that can be edited by anyone and plugins could operate on it. I could use the INCLUDE tag to then include the page in the parent page.

This would essentially create a new page for every table that is entered in. Not sure if this is desirable. Speed might also be comprimised with this approach also.

I will test the FeedbackPlugin and see if there is a way to modify the current implementation such that Plugins can operate on the tables that are created with this patch.

-- ShawnBradford - 13 Oct 2002

Wout,

I definately think data storage is a very weak area in TWiki. If we were to expand the META capabilities I would be very happy. I had to make a lot of little changes to get the TABLE tag to be recognized. It could easily be automated to store a more diverse number of tags. Security is always an issue and speed is also a concern.

-- ShawnBradford - 13 Oct 2002

ShawnBradford, thanks for your comment. As I pointed out above, putting the table information into another medium (e.g., META data) makes it impossible to leverage the many applications developed operating on tables. This is a shame, as this prevents the use of SimpleTableEntryUsingForms for such applications.

Regarding your comment about EditTablePlugin, I think that plugin is quite different from SimpleTableEntryUsingForms in its functionality. Clearly, EditTablePlugin could be improved to provide some of the features of SimpleTableEntryUsingForms, such as fixed size text areas and editing in text areas rather than one line entry boxes, but the mode of interacting with the table is inherently different, as you also point out.

I do realize that there are advantages to separating presentation from storage, but I think the price we pay (not being able to reuse other applications) is too large.

-- ThomasWeigert - 13 Oct 2002

ThomasWeigert,

Understandable. I will work on developing an option that will allow the printing of the table to the file. I still want to maintain the META flexability since it works well with the Form interface. I will let you know when I have a working example.

-- ShawnBradford - 15 Oct 2002

Bug report: Default values for text fields are not inserted when a row is added to a table.

Bug report: When a select field is given a default value other than "", but "" is one of the possible values, when a new row is added it is given the value "" rather than the default value.

Both of these are due to, I believe, that editTable uses Form::renderForEdit to set up the form, but that function is really designed for forms that have their meta data as "FIELD" not in the form used by these tables. ShawnBradford's code tries to sneak existing data values as FIELD metadata into that routine, but that does not work for newly added rows.

NOTE: After testing I later realized that this behavior is consistent with the behavior for standard forms in the Athens release. It is, however, inconsistent with the behavior of EditTable. Either way, I think that this is a bug in form handling. I shall check whether this behavior persists in the Beijing release.

-- ThomasWeigert - 15 Apr 2003

I have generated a fix for above bugs, which unfortunately requires a change in Form.pm also for an unrelated problem: If a default value for a field contains a comma, then this value is split into separate chunks, and any leading and trailing white space is removed. I've patched Form.pm so as to not do that for text and text area fields, as there will never be a choice of values, and there is no other way of recovering the original text.

Note that this patch is against the Athens release...

-- ThomasWeigert - 15 Apr 2003

I've suggested a patch to TWiki which provides default values for all forms (see ConsistentDefaultValuesForForms). If that were introduced, the patch below would have to be adjusted.

-- ThomasWeigert - 17 Apr 2003

I have incorporated the bug fix for the default value setting in editTable script. I have also added a default value for the first column of the table in uploadTable. Both of these should help out with the problem with having empty first columns. Thanks for the update ThomasWeigert.

-- ShawnBradford - 10 Jun 2003

Shawn, I just noticed you made an update today... I feel bad as I had ported this to the latest release long time ago and made many other enhancements, but forgot to post it.

-- ThomasWeigert - 03 May 2005

Thomas, I noticed you ran with the idea and made a new plugin. That is great. I wanted to make the update since I have a lot of legacy pages using the this method and didn't want to convert all the pages.

I also installed your plugin and is looks very nice. I had a couple issue that I wanted to test out before I started using it fully. I wanted to explore some of the following enhancements :

  • Placing the form headings as the first row of the table, I didn't see this as an option for the plugin.
  • Placing the table information on a seperate page and including it through the

Warning: Can't find topic ""."" syntax. This could be an option somehow.

If I can get those enhancements in the EditTablerowPlugin I would be extremely happy. I was going to poke around and see what I could come up with.

-- ShawnBradford - 04 May 2005

Actually, I did two things:

  1. took your SimpleTableEntryUsingForms and made a number of enhancements and made it a plugin (except for the change to Form.pm); we are using this extensively here.
  2. took the idea of your extension and applied it to the standard tables.

I was refering to (1); I should get this uploaded as you might like some of the additions.

On your questions on EditTablerowPlugin, can you be more explicit on what you are looking for? Maybe put it on the dev page there.... I'll implement if feasible....

-- ThomasWeigert - 04 May 2005


Category: TWikiPatches

Attachments

Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm Meta.pm r2 r1 manage 6.8 K 2002-05-31 - 01:34 ShawnBradford Meta.pm library (only added TABLE meta code)
Unknown file formatgz SimpleTableEntryUsingForms20040902.tar.gz r1 manage 13.6 K 2005-05-03 - 17:14 ShawnBradford Updated scripts for the 20040902 TWiki release
Perl source code filepm TablePlugin.pm r6 r5 r4 r3 r2 manage 20.7 K 2002-07-19 - 05:22 ShawnBradford TablePlugin.pm updated library
Texttxt VerificationForm.txt r2 r1 manage 0.6 K 2002-05-21 - 23:00 ShawnBradford Sample Verification Form
Unknown file formatdiff default_value.diff r1 manage 1.9 K 2003-04-15 - 22:59 ThomasWeigert Patch for fixing default values
Unknown file formatEXT editTable r5 r4 r3 r2 r1 manage 5.0 K 2003-06-10 - 18:41 ShawnBradford editTable script
Unknown file formattmpl editTable.tmpl r2 r1 manage 1.8 K 2002-05-21 - 23:00 ShawnBradford editTable template
Unknown file formattmpl editnewTable.tmpl r2 r1 manage 0.7 K 2002-06-03 - 19:25 ShawnBradford editnewTable Template
Unknown file formatEXT uploadTable r7 r6 r5 r4 r3 manage 6.3 K 2003-06-10 - 18:42 ShawnBradford uploadTable script
Edit | Attach | Watch | Print version | History: r39 < r38 < r37 < r36 < r35 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r39 - 2005-05-04 - ThomasWeigert
 
  • 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.