Tags:
create new tag
, view all tags

Allow forms to be rendered as wanted

Motivation

Forms are being used for a wide range of semi-structured pages. Depending on the type of page, you may want a very different display,ranging from prominent on top of the page to a footnote-like addendum,

Description and Documentation

Modify the META tag to be able to specify a template to be used to render the form. The syntax would be:

%META{"form" template="templatename"}%

Where templatename is the name of a template, that will be looked up using the current template path mechanism. This way, template for the forms could be defined in topics.

Examples

Impact

WhatDoesItAffect: Rendering

Original Implementation

(note: I have not reviewed the patch, so I don't know if Peter proposed syntax was implemented. I put in the description section what should be the final syntax)

The patch attached allows a form to be rendered as defined in a template rather than just as a table.

To use this feature, modify the view template (e.g., by creating a skin) to include the variable %META{"formtemplate=xxxx"}%, where xxxx is the name of a template in the current (or indicated) web, probably instead of the variable %META{"form"}%, unless you want both representations of the form data. In this template, one can make use of the variables %META{"formfield" name="yyyy"}%, where yyyy refers to the name of a field in the attached template.

When rendered, the referenced template will be included and the values of the form fields will be substituted for the formfield variables.

The template for the form can be any text or html.

Please keep in mind that this patch only enables the rendering to be controlled by the template; the form is still edited in the conventional table format. This could, however, also be driven by the template, but due to the various type of editing controls it might not be worth it...

-- Contributors: ThomasWeigert - 04 Feb 2004

Discussion

Nice feature!

-- MS - 05 Feb 2004

This is a useful feature. May I suggest to make the syntax consistent with other variables. Motivation: Least surprize for user, e.g. one does not have to remember to use the -r switch for grep, but -R for chmod.

Suggested syntax:

  • %META{"form"}% is the default (current spec)
  • %META{"form" template="xxxx"}% allows you to use a specific template (Thomas' enhancement)

-- PeterThoeny - 04 Feb 2004

Thanks for suggesting to make the syntax more consistent. I shall make that change. Do you have guidance for the fields also or is that one ok? The other option would be %META:FORMFIELD{xxxx}% as in the proposed enhancement to allow access to formfields. There are, apparently two different syntaxes for meta variables....

-- ThomasWeigert - 06 Feb 2004

Also, while this patch does what I wanted it to do (present form content in a different way that conveys the message of the particular topic better) I can see the following enhancement:

A user can add forms to a web, but in the style above, the user cannot add the alternate display if needed, as that requires access to the template directory. For consistency we should also enable the user to select a template for form display, if so desired.

One easy way would be to give an optional parameter to the WEBFORMS preference variable, e.g.,

  • Set WEBFORMS = BasicForm, FancyForm(WithATemplate), AnotherForm

This would always select WithATemplate to go with FancyForm. To allow for variation, we could either allow repeats in this list, as in

  • Set WEBFORMS = FanyForm, FancyForm(WithATemplate), AnotherForm

meaning that the user can select either to have FancyForm rendered in the standard way or using a template, or we could use a list of arguments to the form to indicate the possible templates.

Another alternative would be to add a preference for each form/template combination, e.g.,

  • Set TEMPLATEFORFancyForm = WithATemplate, ExcitingTemplate

Either way the form chooser would show these as different choices, with the same effect as doing the %META{"form" name="xxxx"}% in the template.

Please advise.

-- ThomasWeigert - 06 Feb 2004

Nice to see this. Skinnable forms are (Were :) on my to do list. Although I'm not looking for personalised forms, or different skins per web, but for skins depending on the form name.

Rationale: Forms are being used for a wide range of semi-structured pages. Depending on the type of page, you may want a very different display, ranging from prominent on top of the page to a footnote-like addendum, cf. LessIntrusiveForms. So I figured, the form name would make a good additional key into the template list. Whenever TWiki renders SomeForm for the currentskin, it should look for these templates:

  1. form.currentskin.SomeForm.tmpl
  2. form.SomeForm.tmpl
  3. form.currentskin.tmpl
  4. form.tmpl
This assumes, that no form name and skin name is identical. The precedence of 2. and 3. is debatable. The most important thing for me is to base the look of a form on its function, i.e. the form type, which favours form.SomeForm.tmpl over form.currentskin.tmpl.
BTW
The same approach could solve the problem of IncludeWithFormData. Or is there a way to solve this without yet another template file?.

-- PeterKlausner - 08 Feb 2004

Bumping this up. This looks like an useful enhancement, so I put the right format and distilled an initial proposal for discussion.

- RafaelAlvarez - 25 Aug 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatform TWiki.pm.form r1 manage 1.9 K 2004-02-04 - 23:52 ThomasWeigert Patch for template driven form rendering
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2008-08-25 - RafaelAlvarez
 
  • 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.