RFC Generic Form Handling

[TW_Tones]

Folks,

I want to put “out there” a Request For Comments on developing a shared approach to Form handling in TiddlyWiki. I am not so much looking to make a plugin or solution but to explore the methods to come up with a solution we can all share.

One reason I raise this now, is because of new features in recent versions of TiddlyWiki that have provided new opportunities for form handling such as the cascade mechanism and the ability to edit the current tiddler. A Shared solution will enable the easy sharing of forms designed in the community.

What is a form?

For the purpose of this discussion;

• A form is used to specify a layout that incorporates various information and fields available in a given tiddler beyond the standard fields. Forms can replace just the rendering of the text field or elements on the whole tiddler such as title, toolbars, subtitle etc…
• We could have a form, or pair of forms that can operate in different modes such as the existing view and edit modes or in different modes within the tiddler view.
• Forms can be automatic or customised to a include additional information and elements.

Examples;

• Contact form - accepting various details about people, their contact details and relationships to other details.
• Project tiddler - allowing various project details to be recorded and/or accessing related project tasks.

Forms in Tiddlywiki

• TiddlyWiki forms can be templates we transclude “over” the current tiddler {{||formtiddler}} in a view Template or similar such as via the body template.
• Whilst forms should not be confused with templates used to define a new tiddler, they can also work like a template, for example by providing first-name and surname fields to a “contact tiddler”, will result in contact tiddlers “gaining” these fields with use.
• Forms may be used in different modes such as view/Update/Edit depending on the users access to the Wiki these modes can be handled in different ways;
  • Provide a different form for each mode
  • Have each field respond to a change in mode
  • Modes can apply globally or overridden locally on a given tiddler.
• Would can build a “form design tool” for TiddlyWiki to make “form handling” easier to use.

Questions

• Have you considered the use of forms in tiddlywiki?
• Have you a prefered plugin or method to implement forms?
• Form handling implies field handling, providing different ways to view or edit a fields contents. How best can we support different field types in forms?
• What are your thoughts?
• What would you like in a form handling solution?

[TW_Tones]

Thanks @Charlie_Veniot

@Charlie_Veniot

Think not of forms, but rather think of parts of forms.

I agree totally, as in my post if we build;

• “form design tool” for TiddlyWiki to make “form handling” easier to use and
• Form handling implies field handling, providing different ways to view or edit a fields contents. How best can we support different field types in forms?

Then what you say is true. To build a form it will be useful to do so from subforms and components as you suggest “formlets” and other ideas like interactive fields, these too can be grouped so an “address formlete” may consist of street address/town/state etc… This is in my view the correct way to go.

So to be clear I am all for the formlets/subform and field handling model, but I would not de-emphasis the “form” because this is the method by which the component’s are assembled into real world objects. That is the form is a container for its parts. In fact with smart design these will be nestable containers and can actually approach the “object” method.

Thanks for the componentization link, other models that comes to mind are blackbox and modularisation all of which tiddlywiki is an ideal platform on which to develop and host these.

Thanks for your contribution.

[TiddlyTweeter]

@TW_Tones

That is the form is a container for its parts. In fact with smart design these will be nestable containers and can actually approach the “object” method.

Right. Also, visually it is useful in end-apps to present a “form” as a whole.

My comment is mostly about “what does a user need to see?” The fact the components might be re-done a zillion ways seems subsidiary to end-use objectives.

“Forms”, at end use, do seem delimited to clear aims?

Just a broad comment
TT

[linonetwo]

Do you mean forms that edit the fields of the tiddler?

Then I think Smart Form plugin - beta release - Display different form based on the tag you add - #2 by Ste_W
the smart-form plugin can do it, and it makes sure forms are interoperable and sharable.

[linonetwo]

@TW_Tones

Forms can replace just the rendering of the text field or elements on the whole tiddler such as title, toolbars, subtitle etc

Is this cascade + viewtemplate? But this is somehow beyond the cascade mechanism, because cascade will replace the whole tiddler viewtemplate, but you may want only the title or toolbar part to be replaced.

@TW_Tones

operate in different modes

I think this is like Notion’s database views? It can switch between kanban, list, gallery, table views.

But I think we can make a widget to achieve this, an enhanced dynamic-table widget that can have different views.

[clsturgeon]

I am new to the group (just now). I have been working on a research tracking solution (main focus has been genealogical research) in TW (still experimental). There are numerous entities cross-referencing one another. I needed a mechanism, I think, that qualifies as a form. Having anyone manually populate the required fields was too overwhelming.

I did not want the view mode to have editing capabilities. Rather, I wanted that “form” capability in edit mode.

So, I elected to place the form fields at the bottom of the tiddler in edit mode. The fields presented are tag-based. For example, a tiddler tagged as a person provides a person form. The user can still use the existing TW field controls. My forms appear below those controls. In a sense, the presentation of these fields is not very form-like.

The type of fields I currently have are single-line text fields, multi-line text fields, single-select dropdown, and a multi-select tiddler selector. A good example of the latter is you want to assign/select all people that were present at an event. This would populate the people field of an event tiddler with all of those individuals.

I think my implementation is somewhat brute force. I have a tiddler with all the field definitions and CSS is used to determine what fields appear in the form. In this way, a given form field definition may appear in multiple forms. I want to replace this with some generic–something that can be easily implemented for other solutions and ideas that I have.

For example purposes, here is an example implementation. You may want to review different types of tiddlers–person, event, place, source, and photograph tiddlers.

Churchill Family History (example)

[TiddlyTweeter]

@clsturgeon I looked at what you are doing. Even at this early stage it is really good!

Best wishes
TT

[TW_Tones]

@clsturgeon as @TiddlyTweeter says there is a lot that looks nice on your site.

I too have built solutions “using forms” but I expect like yours they tend to be somewhat bespoke so hopeful people like yourself can share methods used and we can compile them into a “Generic Form Handling” method.

Things I like from your implementation

• I think edit forms in the edit view is a good place to start
• The border delineating the form area with the title on the line
• The fieldnames with White on blue “titles”.
• The Select passenger’s dialogue (I would prefer a modal so the rest stays in place

reimagin-tags.json (9.5 KB)

Things I may change

• It would be nice to find additional ways to visually divide forms into the aforementioned formlets along the same line as your borders
• In the above “reimagin tags” package it adds a lot of features to the tag pill drop down. I would like to have a “Field dropdown” for handling fields including the select and other value selection methods.
• Like the select multiple drop down we really need a library of alternative input (and validation) methods.

Ideas arising from your example;

• It is trivial to move your form up in the edit mode, just as it should be to make the editable form visible in the view mode.

Notes on field handling

• It is worth separating the following for more optimal solutions
  • Field definition (unlimited number)
  • Field Type (One or two dozen different field types would be sufficient)
  • Mode handling (With in type) eg read/edit/update (less than half a dozen needed)
  • Field values entry or selection (Perhaps a dozen or two needed)

Preparing for multiple users

• There is value allowing instances of objects created by forms to exist within a user name space so that these can be merged with a master wiki. So presenting such instances eg a contact as if they were not in a namespace would be helpful in the long run eg “$:/contacts/username/contact name” looks like “contact name”.
  • Alternatively such contacts could be stored in a data tiddler for sharing.

Thanks @clsturgeon for sharing. You can see how valuable It would be, that if I liked one of your objects eg “Business Organisation” I could drag and drop / import the tiddlers to make them in my wiki. ie the forms and new tiddlers etc… were generic, then when one of us creates an “object” all of us can use that object. This is an advantage of a Generic, standard or de facto form solution.

[clsturgeon]

@TiddlyTweeter Thank you. Those Sunburst charts need a better implementation–but small steps forward.

[clsturgeon]

@TW_Tones Plenty of great feedback here. Thank you. I need to review each point and think more about it.

You make some valuable comments, get modal dialogue, which I have been unsuccessful to implement. But I do plan on fixing it. With a more in-depth review, you will uncover other ill behaviour. I’m aware of a few others.

Most of your bullet points lean toward UI. Should we start with the non-visual aspect first?

Some time ago I started a TW5 project that a user could use as a tool to define entities and their relationship. You could define tags and fields (and their type) for each entity along with descriptions of each. It used TiddlyMap to draw an ERD (okay, as close as one could draw an ERD with TiddlyMap). The idea was to first design your system and this TiddlyWiki would generate the needed tiddlers for your project. This is where the project stalled. There are numerous issues that needed to be resolved.

• What tiddlers were to be generated?
• What does version control look like for your project?
• What does the upgrade process look like?

The idea was you started with an empty ERD project and exported results that could be imported into your implementation. When you start a new project you start with a new empty ERD project. I guess I was trying to avoid the end implementation having all this design overhead.

If you liked my Business Organization entity you would not get it from an implementation, you’d get it from my ERD project. Does this make sense?

[TW_Tones]

@clsturgeon

If you liked my Business Organization entity you would not get it from an implementation, you’d get it from my ERD project.

Here we need to differentiate between the object (definition) and instance’s of an object eg How to create a contact, and a specific contact “Jane Doe”. The object definition should be available anywhere it is used, the instances are dependant on the data in a particular wiki.

@clsturgeon

• What tiddlers were to be generated?

If course this could be infinited but I would argue a relatively small number of objects are commonly used and instances one to any number.

@clsturgeon

• What does version control look like for your project?

A who wiki backup can be a version, however there are plenty of ways to capture tiddler versions even without a database and external saves.

@clsturgeon

• What does the upgrade process look like?

What is your concern here?

I have already developed a method for objects to be further upgraded or developed after creation.

[TW_Tones]

I would like to suggest part of the reason I think we as a community have not dealt with forms is in part there are not so much pre-requisits, but many co-requisites to an effective solution.

• Forms require
  • The ability to define and assign forms
    • Forms require variables and fields to be designed for use in forms
    • Fields need to be defined, and can be assigned a field-type
    • Fields may have default or look up values
    • Field-types define such as date, number, text, long text, text are, number, titloe(s)/lists
      • defining a reusable field-type allows it to be assigned to one or more field definitions
  • Tiddler and wikimode handling to move tiddlers and forms between view and edit and other modes
  • view and or edit templates
    • some tiddler type (object-type) handling to identify which view and or edit templates to use
  • A tiddler template solution for creating new tiddlers with a given template for tiddlers of forms.
  • Forms fields types etc… would also benefit from a rich set of custom CSS for styling.

I have buildt solutions and proof of concepts demos for all of the above except CSS, but few if any of this has being published by me, because until I have a unified solution there is too many gaps for other people to make use of the solution.

What are your thoughts?
Am I missing an essential component?
Can you offer some collaboration?
What about the order, placement positioning of fields on forms?

[CodaCoder]

@TW_Tones

What about the order, placement positioning of fields on forms?

Field metadata might be best collected in specialist “metatiddlers”.

• Each field destined to be a part of a form is described by one metatiddler.

• The metatiddler fields describe the properties of the target field.

Using idealized JSON-pseudocode:

metatiddler: {
  title: my-field,
  tags: whatever,
  fields: {
    field-name: Friendly field name,
    field-type: text/int/posint/fp,
    tag: input/textarea/select...
    lookup: {{tiddler!!listfield}} (not sure this belongs here)
  }
}

I’ve squished the fields array for brevity.

That’s just a get-you-started rendition of a half-baked idea, leaving out quotes to aid clarity.

Notionally, it might work to have all fields for a form specified in a single “form metatiddler” though this would limit reuse and encourage metadata repetition across forms:

metatiddler: {
  title: mt-Person,
  tags: whatever,

  fields: [
    {
      name: Name,
      field-type: text,
      tag: input
    },
    {
      name: DOB,
      field-type: date,
      tag: input
    },
    {
      name: Remarks,
      field-type: text,
      tag: textarea
    }
  ]
}

Something like this would work, but, DISCLAIMER: I’m not a fan. It’s too OO and perhaps a little too restrictive. I’m wary of Joe’s gorilla. (Thoughts?)

[TW_Tones]

@CodaCoder thanks for your thoughtful answer. I think there is some merit in the approach you suggest but whatever the solution we need to provide the tools to create and modify the elements. I am sure we could create these for your proposed meta tiddlers.

If a field or form definition resides in a separate tiddler then the view and edit templates already provide some although not all of the tools to edit them.

If the Form metadata (as opposed to Field Metadata) is about the order, placement positioning of fields on forms? then we need ordering of fields (Eg in a field called field-list) but then how do we influence other placement left and right? etc… The same can be asked if we have a set of formletts (which bring their own fields).

All

I have being down these paths a few times, I must say when doing so I feel like “a pig in mud”, and enjoy this conceptual design space. However one thing is clear, it is somewhat self referential, as one builds the tools to handle fields/field-type and forms those tools can make use of the fields/field-type and forms that we are making. There is no doubt in my mind the optimal solution will be the result of a reiterative, self referential design process. This means such a solution needs to to reach a threshold, a degree of completeness before it can be considered a “mature solution” worthy of sharing to the community. To me this means the design approach needs to be one of the following;

1. An individual builds the prototype and experienced users/project participants review and contribute.
2. We have a multi-stranded community project with a lot of collaborative communications.

Each of these have different needs and complexities.

[CodaCoder]

@TW_Tones

how do we influence other placement left and right? etc…

In the metatiddler.

    {
      name: Remarks,
      field-type: text,
      tag: textarea,
      style: background-color:cornsilk;color:<<my-foreground>>;
      width: 12vw;
      height:10em;
    }

That would be do-able. But again, I remain to be convinced – you (we) need more eyes on it.

Positioning should be handled by templates (I’m pretty sure). And if you go with @Charlie_Veniot’s advice (which he mysteriously deleted) “go with parts of forms”, there’s a good reason to have sub-forms (and their templates) handle small collections of fields that notionally “go together”. (But again-again, that’s very OO… feels “unTW”).

[TW_Tones]

@CodaCoder

And if you go with @Charlie_Veniot’s advice (which he mysteriously deleted)

Yes that was very helpful @Charlie_Veniot’s is should have remained.

[CodaCoder]

Something I’ve been thinking about for some time is the idea of a notional runtime tiddler factory where tiddlers can be created “live” by wikitext (so it’s likely a widget) but isn’t stored in the store, it’s created when the wikitext is encountered (just like variables and macros are).

I wonder if it might be of use here…?

The problem is, the more I think about it, the more crazy I think it is

<$make-tiddler title="My tiddler">
  <tags>list of tags here</tags>
  <fields>
    <input name=my-field field-type="date" value=<<today>> ...>
    <input ...>
    <textarea ...>
  </fields>
 ...
</$make-tiddler>

<!-- elsewhere -->

{{My tiddler!!my-field}} ==> today's date

At present, I’m sure that would lose scope unless Ruston Enterprises could marshal it in to global presence.

[TW_Tones]

@CodaCoder

Positioning should be handled by templates

But these templates could be tiddlers, yes?

@CodaCoder

created when the wikitext is encountered

I too have explored something similar. The process needs to create if its has not being created and do nothing if it exists? Perhaps creating “virtual tiddlers” .

@CodaCoder what advantage do you see with this method?

• Is it in a way a pre-formatted tiddler metadata to create new tiddlers?

Could we use the

• TW 5.2.1 added support for throttling refreshes for changed tiddlers with the title prefix $:/temp/volatile/

On creating tiddlers

I like the idea that each object-type tiddler can be created either without a template and just set object-type=objectname (as an example) and all its behaviour is delivered by view templates, forms etc… or if a template is available use that. Whilst additional fields are not created, the user will be prompted to create them via the form.

Using a template to create tiddlers
I also think a tiddler template could accept special fieldnames with a prefix for example the template tiddler would have a “description” field for the template, but if it contains a “_description” field when using the template to generate an instance of this object-type it replaces the templates description with that in the “_description” field. Perhaps “.fieldname” removes the field from the result. eg we may use “_tags” with the tags for the instance (not the templates tags).

Similarly when we create a tiddler we can make use of its context, for example if the current tiddler is tagged with a projectname then the new tiddler should also have the same project name. A form of “new here”. Perhaps the template could have the field &project which says set the project field to the same value in the current tiddler (if it is available).

[CodaCoder]

“Virtual tiddlers” - yep, that’s a good enough name.

@TW_Tones

The process needs to create if its has not being created and do nothing if it exists? Perhaps creating “virtual tiddlers” .

Yes. But… now we’re getting into “instance tiddlers”, which I suppose is unavoidable (even necessary) but that’s very OO and quite unTW.

Without Jeremy jumping in yet, here’s my guess: the parser/refresh mechanism will re-run the $make-tiddler code using the current values stored in the tiddler My tiddler. First time through, they’re likely empty. When you type in a field of My tiddler, the refresh runs again, using the values you typed – I think. At least, that’s how TW does things right now – if you live-edit a tiddler field, any rendition of it renders with your updates.

Honestly, I don’t know enough about tw internals to take this idea any further – I have too many unanswered/unknown questions to know what is and is not viable.

Not only that, I don’t have a good “killer” use-case for virtual tiddlers, other than…

Sometimes, I’m writing a bunch of wikitext and think, “oh, I need to create this other tiddler then come back and use it//transclude it/reference it here”. I wish I could stay in that code and just “make” that tiddler right there on the spot in wikitext. Follow?

As to the rest of your questions:

1. If TW already behaves a certain way, adopt that method first.

2. If not, MSU (make stuff up).

3. Whatever I was going to say before I walked away an hour ago, watched some TV and forgot what it was when I cam back.

There’s likely more I can add in response to your last… but I need to hit the hay.

[TW_Tones]

@CodaCoder

Yes. But… now we’re getting into “instance tiddlers”, which I suppose is unavoidable (even necessary) but that’s very OO and quite unTW.

Having a class of objects and instances, there of, is not a tiddlywiki thing but a real world thing.

• We have cars, I have an instance of a car
• tiddlersa, I just created one
• A contact, I just added one

@CodaCoder

use-case for virtual tiddlers

Actually @Mohammad possibly created a virtual tiddler within Gatha.

Sweet dreams