Concept: FieldWidget

[twMat]

Inline fields. Cool or redundant?

Directly in the wikitext, you mark out specific bits with <$field> tags, for example:

<svg width="22pt" height="<$field name=foo>22</$field>pt" .... ><path ... /></svg>
And the employee of the month is <$field name=employee>me</$field>!

This gives addressable variables, similar to fields, directly manipulable:

<$range tiddler="asdf" field="foo" min="-1" max="10" increment="1"/> 
<$button set="asdf!!employee" ..... />

...and if the <$field> tags encompass larger chunks of text, it'd be comparable to transcluding subsections of tiddlers.

[Alzacon]

I don't know if I understand you. It sounds similar to:
And the employee of the month is <$edit-text field="employee" />!

I don't see the benefit, in the first example, when you have to introduce a widget with a valor vs you create a field and then transclude it. Except to avoid some scrolling to do.

[twMat]

Thanks for feedback Alzacon.

It is not similar to the edittextwidget at all. The closest you can compare it to is a transclusion to a field in the current tiddler, i.e something like

<svg width="22pt" height="{{!!foo}}pt" .... ><path ... /></svg>
And the employee of the month is {{!!employee}}!

Now that I write this... I confess that I kind of wonder what I was thinking. It was something about portability... but, hey, that was hours ago. It does feel appealing to be able to "inject fields" to get a kind of portal right into the content but, as noted, it might just not add anything useful. So, never mind ;-)

[CodaCodr]

@twMat I've long said (to myself, if no one else) the field is the fundamental unit in TW, not the tiddler. A tiddler is a formalized/de facto grouping of fields...

This gives addressable variables, similar to fields,

Fields are global variables, unencumbered by local scope/scoping rules. Not only that, they are true variables. <$set name=X.../> is a local constant.

So yeah, <$field> makes sense (to me).

$0.02

[Jermolene]

Hi @twMat if I understand correctly, the idea is that certain fields of a tiddler be stored within the text body of the tiddler, instead of being defined as separate fields in the usual way. The <$field name="field-name">value</$field> construction is how the value of the field is defined.

One immediate issue is how one would store a field value such as </$field>. We'd have to encode the < characters somehow, perhaps by HTML encoding. So, that means that retrieving or storing the field requires an additional encoding step.

Furthermore, we wouldn't want to have to parse the entire tiddler text every time we need to access the field. Instead, we should parse the fields only when the text of the tiddler changes. So, we'd have a function that extracts all the embedded fields, and keeps them available for when they're needed.

Then, when such a field needs to be written, we'd have to parse the tiddler and scan the parse tree to find the <$field> widgets and their corresponding text. Then we'd modify the text, and save the tiddler again.

So, the trouble is that storing fields within the tiddler body requires much more complexity than the current design.

[AnthonyMuscio]

My feeling has being if we introduced some tools to handle key value pairs, keyname=value

• This would enable aspects of the Original post and other in this thread.

In fact there is already functions for this to handle parameters we just need to expose them more to the user.

If we could parse text, or other fields, identify and extract the key value pairs we could;

• Search for these through out the wiki eg list all titles containing keyname= and extract the value(s) for keyname
• use them to pass as variables to other macros and widgets
• use them to generate field / value pairs
• convert them to JSON or Data Tiddler keys
• Allow the user to type key="value pair" and auto convert this to a field /value pair in the current tiddler.
  -- optionally remove the key value pair from the text.

The idea is to provide some basic handling for a common construct the keyname=value pair and handle the use of quotes around the values then leave it to the user/designer to make use of.

example; type in a tiddler;
caption="My caption"
price="45.34"

• Optionally use a macro or button to turn these into variable/values field/value
• can work a little like a form definition too I will elaborate if we go down this path.

Finally much of this may be easy with the custom wikitext project of PMario, TT and I.

Regards
Tony

[twMat]

@Jermolene - thanks for the detailed explanation! It certainly makes it clear why it is not a trivial matter.

@CodaCodr and @AnthonyMuscio - Like you, I think it there is untapped potential in making fields more prominent in TW.

[CodaCodr]

Here's something I've pictured (using Mat's nomenclature)

<$field name=fieldname /> <!-- read the content -->

<$field name=fieldname value="stuff" /> <!-- set the content -->

<$field name=fieldname value="stuff" return /> <!-- set the content AND return it -->

I'm leaving out tiddler=blah for clarity.

EDIT: these are not intended as action widgets. $action-setfield is fine as it is.

[AnthonyMuscio]

On field handling I have built macros of the form <<field fieldname [mode]>> which determines the current view/edit mode and presents the content of the fieldname in either a formatted view or edit mode depending on a global wiki mode, or if locally overridden.

I mention it here as I think it is the more strategic approach to supporting the concepts raised in the discussion.

I achieve this by having a field definition tiddler, which has a field-type, and then a number of field-type definition tiddlers eg; date, number, short-text .... each field-type provides the wikitext to display such a field-type in what ever mode is selected. And other utility modes you may define for that field.

field and field-type definitions can be used to store other details like column name in lists and tables, default sort order etc...

I also have an optional field called field-list which can be used to present all selected fields, in the specified order and in the specified view/edit mode. This helps with "form building".

Personally I would like to see the community develop a robust support for fields and providing it as a de facto standard at least providing simpler and rapid access to the tools to handle fields, modes and forms.

Regards
Tones

[sourcebert]

@AnthonyMuscio This sounds very interesting! Would you mind sharing an example?

[AnthonyMuscio]

Hi, Sorry, I don't have a "non-proprietry version" of this to share, I used it in building a solution for a client. I have planned to publish it but its quite complex and hard to polish for sharing it. I am also not working at the moment thus can't justify non-core activities.

My comments here cover the issues at a high level. If you have a go you can ask me questions.

[sourcebert]

Thanks Tony! I asked because I'm thinking of a universal TW component library with some kind of a visual ui to build complex forms and other modules. Some of your mentioned ideas could fit into my project. I'm sure I'll come back to you in GG when my concept will reach a more worked out state 😁

[AnthonyMuscio]

You may be interested in this discussion. https://groups.google.com/g/tiddlywiki/c/jZndScUZQck

[AnthonyMuscio]

FYI I am again working on this comprehensive field handling solution, at the moment I do not intend to publish it give the overheads to document it (Unless I get funding) but I am happy to share any methods or magic sauce I discover.

[twMat]

@Jermolene

With the coming JSON store, would this idea somehow be more realistic? I.e the ability to create fields inside the text field?

[pmario]

IMO not really, because the access problem, that Jeremy described won't go away.

[AnthonyMuscio]

I think I have done something similar by coding key value pairs inside a comment block.

eg;

<!--
macroname="example"
macro-syntax="<<example fieldname>>"
-->

Then I wrote my own parser to find and display the results. However except when I am trying to avoid "polluting the field namespace", I am tempted to convert these to real fields. Especially with the JSON tiddler and freer field naming.

I have also thought about providing an edit field in which you type key=value pairs and with a click of a button they are converted to field value pairs in the current tiddler. Just to support the designer. Kind of an edit command line.

Tony