create new tag
, view all tags
At present TWiki form fields are all but impossible to relate back to a form definition once the form has been rendered. This means that authors of Web2-style applications that want to work with the form from Javascript have a nightmare ahead of them. Further, the form definition cannot be determined without a second request to the server.

I propose to add a $id field to the formtables template to support the inclusion of an id on form fields such that the relevant form field can be easily identified in Javascript. This is a critical feature for support of TWiki:Codev.LiveForms.

Impacts the default templates, PatternSkin and ClassicSkin, but as stated before, should be a NOP for all other skins. No new user-visible functionality is added by this change. The changes are generically useful for anyone seeking to interact with form fields.

The specific changes are:

  1. Add class="twikiForm formName:$id" to the div that surrounds the rendered form (it's already class="twikiForm")
  2. Add a class="formData:$id" to the td that encompasses the rendered data for the form field
  3. Add code to expand the $id for the form to the fully-qualified topic name of the form (escaped as a legal CSS class identifier)
  4. Add code to expand the $id for the form field to the name of the form field (escaped as a legal CSS class identifier)
  5. Add code to expand $json to a JSON representation of the form object. This can then be used to communicate the form definition to the Javascript.

Possibly also add the following to the template to transfer the form definition:

<script type="text/javascript" language="javascript">

There is some risk that the class names may overlap with CSS class names already in use. Minimising this risk is the reason for the formName: and formData: prefixes in the class names.

I have already completed this work (including all unit test updates) in a local checkout of the trunk, and am happy to contribute it to 4.2.1, subject to release manager approval. I appreciate this is last minute, but template and core code changes are difficult to ship in a contrib or plugin.

-- Contributors: CrawfordCurrie - 29 Jul 2008


show us the patch smile

When I did something similar in RestPlugin, I found I could leverage the FORMFIELD TWiki Var.

I think form rendering should be refactored to use FORMFIELD, using a format specifier that is defined in a tmpl. That way, skins can use the skin path to change how dynamics like this operate.

-- SvenDowideit - 29 Jul 2008

From reading RestPlugin I can't see how it relates to FORMFIELD. It appears to treat every formfield in a typeless way, which is specifically what I wanted to address by communicating form information to JS. However your point is a very valid one. formtables could be refactored to use FORMFIELD, and FORMFIELD could be refactored to communicate type information to the javascript. That's not what I have done, however. The question is, should we hold off on this proposed change in favour of refactoring formtables? If so, the proposal should be rejected.

-- CrawfordCurrie - 29 Jul 2008

OK, after a chat with Sven I see what he's driving at, and how the approach taken in the RestPlugin may help to address it. I clearly need to do some more research, so I'm taking this proposal off the table for now. We may miss 4.2.1, but so be it.

-- CrawfordCurrie - 29 Jul 2008

A new feature like this would not be 4.2.1 material anyway. We should be very strict and keep patch releases as bug fix releases only. And adding it a few days before release would be totally out of the question even for a major release.

-- KennethLavrsen - 30 Jul 2008

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2008-07-30 - 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.