When is a Form better than an InTopicTable?
Seeing as Peter moved the Categorisations off
Support.WebForm onto
Support.AskedQuestions, I'd like to gather opinions about
the usage scenarios that make it best to use an
InTopicTable:
And when it is better to use a form.
And, indeed, sometimes
BulletFields have their place, so when is this?
Note that from both a visual and data perspective, both are tables. So I use the term
InTopicTable.
I suspect the TopicCreationWizard method predated the development of forms.
Please add to the headings and comment as you see fit.
Schema variability
- Is the user likely to want to add a row or column? Use a table or bullet fields. This is especially true if each user would want to add different rows or columns.
- Is the WikiWebMaster likely to want to amend the categorisations after the topic has been created so that they appear as options during subsequent edits? If so, forms provide a convenient mechanism for doing so.
Purpose
- If the topic describes something and the table is used to help describe it, then the table is part of the content, so use an InTopicTable. If the table describe the topics and can be used to compare this topic to other topics in the same web, use a form.
Multiple tables
Access paths
- Can you guarantee which series of clicks the user will take to generate the page? If not, componentise the creation control into a
COMPONENT COMMENT TWiki.UserTemplates so you can reuse it everywhere. If you can't control all routes, use a form.
Data Integrity
- Does the administrator need to control the set of values picked, or should the user be able to specify? If admin wants control, use a form. If the user should be able to add them, either use an InTopicTable or provide a route through which they can add row to the column in the form.
Searchability
- Is the WikiWebMaster trying to add keywords such that they will only appear in topics that have a certain property? This may add to weight of the argument to use a form because embedding an EDITCELL macro with explicit values for user convenience otherwise makes that topic appear in the search list irrespective of whether that topic belongs to that categorisation.
Cross referencability
- Are you relying on the user to not rearrange the content on the page because you want to use it in a SEARCH? Fear that they will change the labels or rearrange the order? If so, use a form.
Speed of set up
- It seems quicker, easier and neater to me to set up a Form than a TopicCreationWizard like AskedQuestions
Presentation
- Until WYSIWYG is complete (Go go KupuEditorAddOn!!), is the user likely to dislike if they see raw text on their second and subsequent edits? If so, use a form.
--
MartinCleaver - 20 Oct 2004
Great stuff - I can't think of anything to add, and it certainly opened my eyes to some things I hadn't thought of.
--
MartinGregory - 23 Oct 2004
I'd like to suggest that the good summary by
MartinCleaver should be used as a list of whats wrong with the current
TWikiForms system, and would like to see some discussion on how we change it to allow more flexibility. I'd like to see Form data to be able to be rendered as tables / bullets or whatever, for there to be permissions on
FormFields, for users to be able to add user specific data to Forms, (which might be stored seperatly from Admin defined data).
Or maybe there
needs to be a query / addressing & rendering system that allows users to treat Bulleted,
TableBased data in the same way as Forms data (i guess thats back to having a better
TWikiQuery system)
--
SvenDowideit - 24 Oct 2004
I assume you are aware of Crawford's excellent
FormQueryPlugin?
--
ThomasWeigert - 25 Oct 2004
Not only am I aware of it, but I suggested in
CorePackageCandidates that
DBCacheContrib, FQP's underlying data engine, be bundled in the
CorePackage.
--
MartinCleaver - 25 Oct 2004
Conv moved to
ConfusingTerminology
--
MartinCleaver - 26 Oct 2004