Tags:
create new tag
, view all tags
The following preceeded the first release of the FormTemplateSystem. Some of it is now out of date.

Questions

  • [ JohnTalintyre ] - why have the Type column in the definition of a list e.g. in TopicClassification above?
    • [ PeterThoeny ] - To avoid unwanted side-effects; for consistency.
      • [ JohnTalintyre ] - Perhaps I'm missing something here, but I can't really see possible side-effects or consistency issues here.
        • [ PeterThoeny ] - You get an unwanted side-effect if you have another table in the template topic besides the form definition table. To be more concrete, requiring option allows you to simply scan for lines of format \|\s*(.*?\s*)\|\s*option\s*\|\s*(.*?\s*)\|. That way you can also split up the table into two or more if you like and chose arbitrary text for table headings.
          • [ JohnTalintyre ] - I see what you're getting at now. At present the table heading is checked and must contain the word Name for subsequent lines to match.

  • [ JohnTalintyre ] - do we allow form templates to be shared between Webs. I think for consistency we should.
    • [ PeterThoeny ] - Makes sense. Needs to be coded accordingly, in a similar way like %INCLUDE% does, i.e. by adding the web name to the topic name in case it is not the current web.

  • [ JohnTalintyre ] - if a topic is moved to a Web (with different form templates) what do we do? We could refer back to the old definition when viewing, on edit could give choice to change to another form template.
    • [ PeterThoeny ] - For simplicity I suggest to keep the current form, e.g. the form points back to the original form template.

  • [ JohnTalintyre ] - the above specifies tooltips. These won't appear when viewing the topic as normal rendering will just see these a WikiNames. Does this matter? It does raise the more general issue of tooltip for topics, a topic could store a tooltip within it, possibly as meta data, but cost would be moderatly high for reading it out when refering from another topic.
    • [ PeterThoeny ] - I was thinking of showing the tooltips just in edit for the links opening up the popup help windows.

Ideas

The TEXTAREA widget is just a special type. It would be useful to be able to include that in the form template. That way you have control where the TEXTAREA is in regards to other form fields, i.e. you could set the form fields above the free form TEXTAREA, or you could get rid of the TEXTAREA all together to get a true form. Note: Probably best to postpone that until after the release.

  • [ JohnTalintyre ] - interesting to think about, but agree, something for later
  • [ RichardDonkin ] - I'd like to see more than one free-text field per form (not just the default TEXTAREA) - this would be useful for Q&A type knowledge bases where you want to search only on the question, for example.
    • [Main.JohnTalintyre ] - an interesting point. Unfortunately it will require a topic format change as present form based approach has each form field on one line.

Creating new topics with forms

When you create a new topic in a web that has the WEBFORMS preferences variable set you will get a topic with the default form template specified by the variable.

For simplicity we should use the default form template when one creates a new topic by question mark link or "Go" field, i.e. better not to show a menu to select a form template.

  • [ JohnTalintyre ] - okay, why not have this happen if there is only one form template, but otherwise have selection option. There should be the option to specify the required form template, probably via the existing templatetopic query parameter, with form added to the template topic in the normal way.
    • [ PeterThoeny ] - More at "UI for multiple form templates".

Topic meta data

See MetaDataDefinition.

The form template topic name and all form fields/values are stored in the topic meta data. The form template topic name is needed for edit and save.

The order of form field/value items in the meta-data is the same as in the form template.

Multiple forms per web

Currently only one form template can be defined per web. For WorkFlow systems it makes sense to allow more then one form template. I.e. you have a set of form template topics like expense report, vacation request etc. When you create a new topic based on SelectableNewTopicTemplates you basically instantiate a new expense report, vacation request etc.

Note: Probably best to postpone multiple forms per web until after the release.

  • [ JohnTalintyre ] - I'm inclined (well I already have) put capabilities in for this. I think the main issues are UI based, so if these are not resolved we'll still have the basic capability in the release for people to experiment with, but no out-of-the-box UI.

UI for multiple form templates

The main issue here is selection of the required form. In the old category system this was done by the special UseCategory field. This has the advantage that this is all done on the edit page. But, without using Javascript it is difficult to deal with multiple form templates. I also find it confusing the the form was shown even if UseCategory was set to No.

  • Optional WEBFORMS variable defines possibles form templates that can be selected after pressing button on edit page
  • A template topic can use any form template
  • Decided not to ask user to choose a template or form template when creating a topic as goes against the KISS of Wiki systems.
  • New topics with a form get instantiated by simple HTML forms asking for a topic name, i.e. there is a SubmitExpenseReport topic were you can create new expense reports, a SubmitVacationRequest topic and so on. These can specify the required template topic and hence form

  • [ PeterThoeny ] - Change form: I think it is important to make it not too easy to change the form of an existing topic, you would get unhappy users if they hit a button by accident and all the form data is gone. So, don't offer it at all, or only for admins.
    • [ JohnTalintyre ] - This sounds a bit like many people initial reaction to the democrarcy of Wiki ("you mean someone else can alter my topic"). I guess the difference here is the action is just one click, but the effect significant and what's worse, someone might not even notice. I think this point towards a two step process, screen with form template choice and warning displayed, before going back to edit. This process could be secured, so TWiki admin can opt to limit capability.

Migration of Category information

Principle: new system should work with old data with no special conversion.

Old data should be transparently upgraded to the new meta format when a topic is edit/previewed/saved.

On upgrading the administrator must produce a form template topic for each Web that using the old category system. twikicatitems.tmpl defines the categories and is used in the conversion. The form template must be put as first item in WebPreferences variable WEBFORMS. If it's not present, use edit gives an oops dialog.

Questions

  • Do we need script to upgrade all topics (running would be optional)?
    • [ PeterThoeny ] - I don't think this is needed, but could be offered for convenience.

Future

Please see FormTemplateFutureIdeas.

Feedback

It is getting late, I hope I have most of the feedback incorporated.

-- PeterThoeny - 19 Jun 2001

Glad that you both like the new terminology smile I think that 'form field value template topic' is quite accurate, as it is defining allowed values for a field, but it's a bit of a mouthful - how about 'field value template'? It should be clear from the context that fields apply to forms, and of course everything in TWiki is a topic.

In the longer term, I'd like to see more than one free-text field per form (not just the default TEXTAREA) - this would be useful for Q&A type knowledge bases where you want to search only on the question, for example. However, this is just a refinement and does raise a few issues since TWiki is built around a single free-text field.

  • [Main - JohnTalintre 4 Jul 2001] Not exactly what you wanted, but textarea is now another type that can be used. This was an easy change, change main edit box will (I think) be harder and is something for another release.

-- RichardDonkin - 19 Jun 2001

Coming together well, I like the new naming conventions. I've changed this page to use headings and %TOC%, hope that works well for everyone. Please see my "* [ JohnTalintyre ]" bulleted notes above and the new spec section #UI_for_multiple_form_templates, plus the migratin section.

-- JohnTalintyre - 20 Jun 2001

I now understand what Category table was all about, so that's definitely progress! Can we name the Form with a WikiWord though. Any suggestions?

-- MartinCleaver - 20 Jun 2001

A few more thoughts above - see "* [ JohnTalintyre ]".

-- JohnTalintyre - 20 Jun 2001

All of this sounds good! I especially like the possibility of creating a template that controls the location of the TEXTAREA as well as the other fields. (And I imagine I'll find a way to live without the twikicatedit.tmpl, etc.)

-- RandyKramer - 21 Jun 2001

Do you mean where TEXTAREA sites on view, preview or edit? At a later date will can always bring back something like twikicatedit.tmpl if the demand is out there.

-- JohnTalintyre - 21 Jun 2001

John,

Sorry I wasn't very clear -- I was referring to the first item under "Ideas" above, which is:

 
The TEXTAREA widget is just a special type. It would be useful to be able to include that in the form template. That way you have control where the TEXTAREA is in regards to other form fields, i.e. you could set the form fields above the free form TEXTAREA, or you could get rid of the TEXTAREA all together to get a true form. Note: Probably best to postpone that until after the release.

Whether its done using the twikicatedit.tmpl or some other mechanism doesn't matter to me now -- I'm assuming there will be a mechanism to allow controlled placement of the "form fields" on a page, even if it doesn't initially allow control over placement of the TEXTAREA. At the very least, I'd want to display the fields as a bulleted list (see DisplayingCategoriesAsABulletedList) rather than a table, but I'd also like to:

  • Display only selected form fields on a view, and perhaps others on a preview, or something like that.
  • Display some form fields before the TEXTAREA.

-- RandyKramer - 25 Jun 2001

I removed DEFAULTFORM, as I think that WebTopicEditTemplate already gives this capability. In fact, it also allows initial values to be set as required. Having done this, I know realise that unless WEBFORMS is in place, there's not way of adding a form to a topic that doesn't have one. Sigh! So unless everyone overjoyed at WEBFORMS and change to edit script, I'll add back DEFAULTFORM (now DEFFORM) and UseForm as special form field.

I've put in =WEBFORMS as a parameter in WebPreferences. It is optional. When given an extra button is added at the bottom of the edit page. Press this and you get to choose any of the forms listed in =WEBFORMS, plus the choice of no form. Warning is given that old form data will likely be lost. Your then taken back to the edit page when new form template is chosen. I had to implemented some of this in the preview script, which is not great (I needed to pass on the textbox and hence needed (I think) to post to the same script that was already used for the form. Fancier Javascript could get around this, but this could lead to compatibility problems.

-- JohnTalintyre - 26 Jun 2001

An earlier design decision was to not read the FormDefinition when viewing a topic (that used this definition). The reason was one of efficiency. However:

  • Many plugins already read in topics
  • Title information has already been copied to the meta data as consequence and now there is the issue of tooltip data.

Should we change to read the definition on view?

-- JohnTalintyre - 11 Jul 2001

I would not do that unless there are very compelling reasons. Think about a search with 500 hits...

-- PeterThoeny - 11 Jul 2001

The hit would only occur on rendering the form data, this would not occur with a search.

-- JohnTalintyre - 12 Jul 2001

Unless you have a BookView search. Also, a diff all of a topic with many versions would be hit. Therefore, how about inserting all needed info into the meta-data?

-- PeterThoeny - 12 Jul 2001

Mentioning BookView reminds me that topic inclusion is an issue. BookView should show form data, should it also show attachments, I assume so. But, what about included topics? Previously they had to show categories and attachments as these were HTML, now there's a choice.

I think the efficiency issue with BookView is easily dealt with by caching the form definition information, similar to Plugin behaviour. I don't think a topic diff is affected, as meta data is not rendered. I agree that adding extra meta data is fairly easy, but my database instincts cry out against too much de-normalisation.

-- JohnTalintyre - 13 Jul 2001

I don't think we should try too hard to optimise the BookView case if it means extra complexity - anything that returns a large number of pages as one page shouldn't be expected to be very fast, and I don't think people would often do such searches in the sort of TWiki web that uses forms, although I guess that's partly up to the web designer. It's conceivable that embedded searches would return whole pages, I suppose.

-- RichardDonkin - 15 Jul 2001

DEFFORM facility has now been removed. Previously we had DEFFORM and and WEBFORMS. Problems with this were:

  • Confusion in use
  • Special case in code - turned out more complex than I'd expect.

Downside might be more clicks to add a form. However, I hope that with appropriate use of WebTopicEditTemplate and embedded forms this will not be a problem. WEBFORMS does allow multiple form templates per Web, so let's hope this new facility will prove useful.

-- JohnTalintyre - 16 Aug 2001

TopicClassification:
FeatureDone
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2001-08-16 - JohnTalintyre
 
  • 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.