Tags:
archive_me1Add my vote for this tag dakar1Add my vote for this tag create new tag
, view all tags

Bug: Various problems related to forms handling in Dakar

1 When changing form, the current form is not correctly indicated in the radio field 4160
2 When adding form, the radio field does not correctly indicate that currently no form is attached. 4160
3 Empty form fields should be rendered as   otherwise the output formatting in ClassicSkin is messed up. 4160
4 Question: In Cairo under ClassicSkin, forms were rendered as TML tables, and thus formatted by the current table settings. In Dakar, forms are rendered as HTML tables with no formatting. What is the desired appearance for forms in ClassicSkin? 4202, 4277

Test case

Follow up

On point 4: Good question, I do not know why. For nicer table rendering of skins not using style sheets I would like to see this reverted to generating TWiki tables.

-- PeterThoeny - 01 May 2005

Final dispensation of point 4 is to use HTML tables, and use white background. Users can customize the form rendering on ClassicSkin via CSS, if desired.

Fix record

Implemented 1-3 as 4160 (for UI.pm) and 4198.

4 reverted to Cairo 4202.

Avoid creating a header cell when field is all bold-faced text in 4229.

4 finalized in 4277.

Discussion

Fair enough. I made the change to HTML tables to avoid the complexities of escaping "illegal" characters in the table. I'll try putting them back to TWiki tables, see if it works OK now.

-- CrawfordCurrie - 01 May 2005

Good point about escapes, which I did not think about. It looks like the only char that might interfere is the pipe |, which can be escaped with |

-- PeterThoeny - 01 May 2005

OK, I changed it back to a TWiki table.

-- CrawfordCurrie - 01 May 2005

Don't worry, the escapes are all in the code already from before....

-- ThomasWeigert - 01 May 2005

Hmmm. Now we have the following problem: If you have a cell where the content is just bold-faced text, this cell will be formatted as a header row.

I am not sure what the spec says on table formatting: Does every bolded text get formatted as header cell, or is this only the case when a full row is completely bolded?

-- ThomasWeigert - 02 May 2005

Avoid creating of header cells by custom treating bold facing of text. Not very satisfactory, as this duplicates * handling, but other than changing again to HTML tables or making a change to emitTR to avoid doing this for all tables I can see no other choice (I guess we could render each form field separately before rendering the page, but that would slow things down a little.)

In SVN 4229.

-- ThomasWeigert - 02 May 2005

The behaviour of cell rendering is the same in Cairo (and Beijing) viz bolded text results in a header cell. Having said that, I agree with your fix (though I have tidied up the implementation a bit so it doesn't depend on the semantics of *text*)

SVN 4244

I remember now why I switched to HTML tables;  |  has to be escaped as well (and any variable values that may contain TML after being expanded). We're caught between a rock an a hard place. Use TWiki tables, and have them corrupted whenever TML syntax is used in values (or any other syntax innocently added by plugins) or use CGI tables, and lose reformatting by plugins.

SVN 4249

-- CrawfordCurrie - 03 May 2005

Can you give an example of "any other TML that needs to be escaped"? I think the key problem is  |  (and the bold cell if that is considered a defect). But what other TML is there causing a problem?

-- ThomasWeigert - 03 May 2005

I see, it is both  |  and %SEP%... One option would be that we render each form field before assembling the table. This would get rid of the special case handling for bold text, and we can then just handle  |  as needing to be escaped. I guess the performance hit is small?

I am also ok with rendering the form as all white in ClassicSkin (i.e., going back to HTML tables).

-- ThomasWeigert - 03 May 2005

How does the RecursiveRenderPlugin solve this problem? -- FranzJosefSilli - 03 May 2005

  • By the same strategy... render before inserting into table.... -- ThomasWeigert - 03 May 2005

Thomas, other TML that needs to be escaped. Another example would be a plugin tag that expands to a TWiki table. Pre-rendering the form values doesn't work either, unless you post-process to encode the funnies like newlines and | and any occurence of %SEP% in the rendered output, which kind of blows away the advantages.

The disadvantage of going to HTML tables is that we lose the ability to tweak the table from a plugin. I'm not sure you'd ever want to do that, though, or even that it's a good idea to allow it. Peter, you were arguing for TWiki tables above. Given the problems described above, are you sure you still want TWiki tables?

-- CrawfordCurrie - 05 May 2005

I agree that it is unlikely that the form would be tweaked from a plugin via the TML. More likely the plugin could define CSS for which the hooks are there presently.

-- ThomasWeigert - 06 May 2005

See also http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item10

OK; then unless Peter expresses an opinion, I'm going to switch back to HTML for the forms.

-- CrawfordCurrie - 07 May 2005

Crawford, given all the considerations above, I'd say, go for it. Let's decide on the appearance of the form in ClassicSkin. I'd say, make it all white background and normal text, i.e.,, just as you had it.

Sorry for starting all this commotion with the innocent question (4).

-- ThomasWeigert - 08 May 2005

Not a problem; debate is healthy, especially when backup up by experiment. Done in SVN 4277

-- CrawfordCurrie - 08 May 2005

OK, the HTML table is a disagree and commit thingy for me. smile

However, I do not agree that the recent spec change is OK of rendering | *cell text* | as bold instead of a table header. The TextFormattingRules doc states that "| *bold* | cells are displayed as table headers."

This spec change results in unexpected rendering of existing TWiki text. We need a better way of vetting proposed spec changes. The TWikiMission clearly states to " Protect corporate investment (topic contents) from data corruption and incompatible changes"

-- PeterThoeny - 11 May 2005

Peter, there are two separate things going on here:

  1. How should | *cell text* | be rendered in a form?
  2. How should *field text* be rendered in a table field?

Clearly these are not the same question. The spec you quote speaks of rendering in a table, and nobody has proposed changing that. However, it appeared to me that bold text in a form field should not be rendered in the style of a header cell in a table but as bold text. The user who entered the form field does not even realize that the form might be rendered using the machinery of a table. Note that, in addition, in athens forms were rendered as HTML (and even in beijing, I think).

So I don't think that any spec has been changed.

-- ThomasWeigert - 11 May 2005

We can distinuish between regular TWiki tables and TWiki Form table (although the second one is a moot point since it is now rendered as an HTML table). Agreed that for TWiki Form table cells, *field text* should be rendered as bold, and not as a table header.

For regular TWiki tables we should not change the spec, that is | normal cell | _italic cell text_ | normal and *bold text* | *cell header* | should render as:

normal cell italic cell text normal and bold text cell header

Good if this is the case; I was confused by the comment in Support.WikiTableDataFormatting

-- PeterThoeny - 11 May 2005

It's the case; see the testcase

-- CrawfordCurrie - 11 May 2005

However, there are two problems in table formatting tangential to this topic. See a version of Crawford's text case:

A0 all rows B0 C0 widen this col D0LinkInColHeader E0* not a link this *time
B1 left C1 center D1 right E1* is *strong

The top row (original *D0LinkInColHeader* ) shows the *, for some bizzare reason. The second row (original *E1* is *strong* ), in my opinion, should not be treated as a header cell, as it is not a single text all bold.

-- ThomasWeigert - 11 May 2005

Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2008-09-17 - TWikiJanitor
 
  • 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.