Feature Proposal: Prevent premature tag expansion in editable tables

Motivation

Here is a nasty problem:

In the editable tables (provided by EditTablePlugin, EditRowPlugin, etc.) we want to be able to enter standard tags in the table cell.

In all tables, we want to be able to use the SpreadSheetPlugin.

Now we got a problem:

In order for the editable tables to preserve tags, these plugins must operate before TWiki::expandAllTags, i.e, the must run the latest in beforeCommonTagsHandler.

However, SpreadSheetPlugin runs in the commonTagsHandler.

So, either

• we cannot have spreadsheet calculations in editable tables, or
• we get tags expanded the second time we edit an editable table.

We actually went around this circle already once before, with EditRowPlugin. At that time, I believe, an incorrect decision had been made in that the editable table tags have been pushed back to the commonTagsHandler.

I believe that this decision was incorrect because we must have both features together. It is not acceptable that tags in edit boxes are expanded when we edit them a second time. Note that then these tags get saved expanded into the topic. This is bad.

It is also not acceptable to have to protect these tags by some special syntax, such as $percnt as this are normal tags. If we would have typed them in some other place, they would have worked fine.

It is also not acceptable to not have SpreadSheetPlugin apply to editable tables.

Description and Documentation

I see the following solutions:

1. Move SpreadSheetPlugin earlier.
2. Agree that SpreadSheetPlugin will not work on editable tables when we are in edit mode and attempt to break the edit table plugins into two pieces, one piece that fires for editing (before common tags get expanded) and one piece that fires for viewing (when common tags get expanded).
3. Have the edit table plugins remove the section to be edited before the common tags handler is expanded, allow the common tags to do their thing, and finally, put that section back in.

Any thoughts and ideas?

Peter will have to comment regarding the SpreadSheetPlugin moving. It is clear that the second and third option will increase the cost of rendering, as every table in the topic will have to be processed twice.

Examples

Impact

Implementation

-- Contributors: ThomasWeigert - 2010-09-19

Discussion

I have tested solution #2 in a preliminary prototype for EditRowPlugin. It seems to work, but it does require every editable table to be parsed twice, plus some preliminary processing. The rendering of the table happens only once.

Solution #1 will be more implementation work, but will also require double parsing. It will be slowest in terms of processing time, but it will allow the SpreadSheetPlugin to perform calculations even on the table being edited (albeit that might be not that useful anyway).

-- ThomasWeigert - 2010-09-1t

Agreed, editing a table should have the same effect like editing the whole page, e.g. variables should survive and should not get expanded.

I am wondering if there is a generic way along these lines: The EditTablePlugin escapes all variables in beforeCommonTagsHandler, regardless of type for just the table that will be edited in a later rendering step. It needs to be escaped so that the table cells show the variable verbatim, such as %CALC{$SUM($ABOVE())}%. That possibly could be done by using the HTML entity for the percent sign, %.

-- PeterThoeny - 2010-09-20

Yes, that would be possible to, but it would also require a double parsing of the table.

In either case, I have fixed the EditRowPlugin, and made some other fixes to it. (I am surprised that Crawford had missed some obvious, but small problems.)

The price is the double parsing.

I wonder if you could study whether it is possible to move the SpreadSheetPlugin before tags expansion?

-- ThomasWeigert - 2010-09-20

Please make sure to checkin, build and upload your plugin fixes.

I need to study the SpreadSheetPlugin change, I am concerned that changing the evaluation order might break some existing TWiki applications.

-- PeterThoeny - 2010-09-20