SuperTag plugin, auto-generate a field editor on view template

[linonetwo]

By simply adding a SuperTag to a tiddler (For example, Task), you will see a form showing in your tiddler (e.g. completed and completeType field editor), see screenshot below:

The field is only shown if your tiddler already had this field. To edit non-existed field that defined by SuperTag, click " ≡ properties" button to expand the available field editor list:

For how to use SuperTag, and how to create your own SuperTag for you or your plugin’s user, see SuperTag plugin’s demo site.

Github: GitHub - tiddly-gittly/super-tag: Define schema for a tag, add tag to get a form based on schema.
Demo: SuperTag plugin’s demo site.

It has zero dependencies, so you can drag it to your wiki, or install it from CPL.

---

related:

• Tana - Supertags are the backbone of Tana, it’s how you can give structure and context to item lightning fast, keeping your flow.
• Smart Form plugin - beta release - Display different form based on the tag you add
• @joshuafontany GitHub - joshuafontany/TW5-jsoneditor: TiddlyWiki plugin for creating json forms using json schema
• @btheado Are you still using this? Do you have demo site or usage doc? · Issue #2 · btheado/jsoneditor · GitHub

[btheado]

Nice work! That’s a good idea to use jsonschema to a render a form for editing the fields of the current tiddler while in view mode.

I notice your super-tags widget is very opinionated on how it will find the schema. It requires the schema to be stored in the schema field of a tidler which is tagged with $:/SuperTag/TraitTag. The schema tiddlers can’t be used directly and instead another level of tags is required.

This “opinion” is hard-coded in the typescript so it can’t be easily changed.

What do you think about having an attribute on the widget which expects a filter to be given? The output of this filter will be a list of jsonschema which will be used by the widget. If the attribute is not given, then it can default to what your typescript is doing (I think this is equivalent to your code):

[all[current]tags[]tags[]] :filter[tags[]match[$:/SuperTag/TraitTag]] :and[get[schema]]

That way the user can create their own view template which can trigger on a word in the title or some other condition and the schema can be chosen by means other than the specific tag structure you’ve chosen.

[linonetwo]

I didn’t figure out this filter expression, the version i wrote was full of bug so i decided use js for this logic. And I thought there can be other widget to run other logics.

Now that you have this working filter expression, I can add it as default filter, and make the only widget customizable, thanks. I will add it in the next release.

Another reason I use js for this, was that I used to try using jsonforms library at the beginning, it supports uiSchema field, so I need to get two fields out of them, which can’t be done by filter expressions easily.

[linonetwo]

V0.1.1

!!! General propose JSON Form Editor

See [[WidgetExamples]] or [[Examples]]. (on demo site, of course)

<$json-editor-form filter="[[ExampleSchemaRendering]get[schema]]" tiddler=ExampleSchemaRendering />

This is only provided as a tool for plugin developers to build custom forms.

For interoperability consideration, it is better to use the TraitTag approach described above, so our TiddlyWiki developer community can have a consistent way to deliver forms to end users. And our plugins can work together seamlessly as described in Suggestion for all Plugin developers about field name: Let’s use Ontology to maintain Interoperability.

[linonetwo]

Chat with a friend today, and he introduce Potluck: Dynamic documents as personal software to me, which inspire me that we can write some regex rule or prompt (for GPT), to auto extract tiddler content, and fill into the form provided by supertag.

[Scott_Sauyet]

@linonetwo

Chat with a friend today, and he introduce Potluck: Dynamic documents as personal software to me

Wow, that’s fascinating. I hadn’t seen that before. Definitely has some overlapping ideas with TW.

[abesamma]

This is excellent progress towards making TiddlyWiki more proactive and “intelligent”, i.e. a knowledge engine while furthering interoperability between plugins and data. I think the biggest challenge facing us as a community now is agreeing on standard ontologies with which we can reliably design around. I’m working on furthering this idea on my end with working demos, but I strongly urge folks in the community throw some working ideas out there to see if we can make something out of this supertag innovation. Congrats and many thanks once again to @linonetwo for moving us in this direction with working software.

[TW_Tones]

@linonetwo

Potluck: Dynamic documents as personal software

This ties in with my classification of TiddlyWiki as a smart document.

In someway’s with tiddlywiki the PotLuck approach is not new, but they put it so elegantly;

We think a promising workflow is gradual enrichment from docs to apps: starting with regular text documents and incrementally evolving them into interactive software. In this essay, we present a research prototype called Potluck that supports this workflow. Users can create live searches that extract structured information from freeform text, write formulas that compute with that information, and then display the results as dynamic annotations in the original document.

There email; addresses are on that page, has anyone contacted them about TiddlyWiki?

[abesamma]

@TW_Tones

There email; addresses are on that page, has anyone contacted them about TiddlyWiki?

I remember listening to a podcast episode where the creators of potluck talked about their insights from their project. It was quite fascinating and it was strikingly similar what we do everyday in tw5. Don’t know if they’re aware about us, but we definitely should exchange notes with them.

[Offray]

I saw a lot of resonances of that article, when I read it, with TiddlyWiki on one hand and computational notebooks (like the ones from Mathematica, Jupyter, OrgMode, Grafoscopio, Lepiter) on the other (as I said before we’re combining TiddlyWiki with computational notebooks with TiddlyWikiPharo).

This progression from dynamic documents to apps has been explored in several places/times, and from our workshops over here, seems pretty empowering as a way to go from the popular “end user” practice of computing/informatics to “power user” just doing and automatizing the day to day life things and having a better place to do them that word processors, spreadsheets and slide presenters. How this progression is made, is where a system like TW (or Pharo/Smalltalk powered systems) shine, as they blur the distinction between the app and the IDE (which is not so clear in others or even with a pretty big discontinuum). And in such blurring, being meta-systems (made/extensible on themselves) marks a big difference.

The research explorations from Ink and Switch, also with local first software, have a lot of connecting nodes with practices like the ones empowered by TW. For example, TW is a local first portable “cloud document” (if local savers are enabled). Connecting our day to day practices with those more “researchy” explorations seems a way to bridge “explorations in the lab” with “explorations in the wild”.