Fields should have definitions

[bimlas]

I'm developing a plugin that lists the values of the fields. As I was writing it, I had to realize that fields can be very useful, but I feel like they're hanging in the air because there is no definition for them (so I implemented most of the following ideas in the plugin).

For example, from the "list" field contains a list of titles, so the titles must be listed in the form corresponding to the list:

[[first title]] second [[third title]]

This operation is only referenced in the documentation, but if we haven't read it, we don't know about it and do not understand why it treats the words "first title" separatelly (which should have been correctly entered as "[[first title]]"). I think we should create a field definition that indicates that eg. "list" filed is a field containing a list:

title: $:/config/fields/list
field-type: list

In addition, this definition could provide a template that Tiddly could use to display the elements of the field, for example for tags:

title: $:/config/fields/tags
field-type: list
template: <<tag>>

Because we know how to handle the contents of the field, we even have a template for its elements, so each field could have auto-completion and "proper" rendering, so every field could work just like tags.

I don't know if this change fits into TW 5.2 or just TWX, but I think it would greatly facilitate the use of fields.

Example from the wild to this: https://github.com/zadam/trilium/wiki/Attributes

[Mohammad]

In TiddlyTables, templates have been developed to treat each field differently!

In Favorites plugin list field has been used to create folders

On Saturday, January 4, 2020 at 11:28:47 PM UTC+3:30, bimlas wrote:

I'm developing a plugin that lists the values of the fields. As I was writing it, I had to realize that fields can be very useful, but I feel like they're hanging in the air because there is no definition for them (so I implemented most of the following ideas in the plugin).

For example, from the "list" field contains a list of titles, so the titles must be listed in the form corresponding to the list:

[[first title]] second [[third title]]

This operation is only referenced in the documentation, but if we haven't read it, we don't know about it and do not understand why it treats the words "first title" separatelly (which should have been correctly entered as "[[first title]]"). I think we should create a field definition that indicates that eg. "list" filed is a field containing a list:

title: $:/config/fields/list
field-type: list

? this is not clear

 

In addition, this definition could provide a template that Tiddly could use to display the elements of the field, for example for tags:

title: $:/config/fields/tags
field-type: list
template: <<tag>>

--Mohammad 

[PMario]

Hi,

The boot.js contains some "tiddlerfields" module definition, which allows special handling for different field types.

They are loaded in load-modules.js and are accessible with the $tw.Tiddler.fieldModules object.

So it should be possible for plugins to define new .parse() and .stringify() methods that can do "special" handling.

If a tiddler is created it uses the .parse() definition. see: boot.js line 906.

$:/core/modules/tiddler.js uses the .stringify() method to read .getFieldString()

I think those elements need to be exposed and explained a bit better, so they can be used by end-users. I also think, that the core code has some inconsistencies in the "field-handling" methods, that can be used. .. NOT 100% sure here. Need to investigate.

-m

[TonyM]

Bimlas,

I have produced a commercial solution on tiddlywiki. To save time I developed a field definition solution and learned a lot in the process. No javascript needed it works very well. The key design points are below;

• How do you reference the field(s)? Via the view template using a macro and always `<<field fieldname>>`, so the macro can handle the work. Rather than use the edit template we can change the tiddler mode, and edit in line. This method allows editing fields in the current tiddler.
• The field macro looks up a field definition in a tiddler named $:/fields/fieldname and retrieves its field-type, and the values or filter to retrieve its possible values
• The field macro then looks up the field-type definition which is like you may think of a field definition but is reusable for multiple fields eg text, text area, yes/no, date, icon etc...
• Then depending on a mode one of the field-type's fields will be transcluded, (one according to the mode), this field contains the wiki text for handling the field in each mode
• The Current modes I use are read-only, update and edit and as needed. These are derived from a global setting or overridden with a local tiddler mode.
• With the field macro you can override the current mode `<<field fieldname edit>>` or even the field-type.
• In one case I use an extra mode called "number" which returns a computed number for a date ie years old, this is another field in the field-type tiddler

I believe the formalisation and documentation of this process built collaboratively for peer review is all we could want. It need only be a defacto standard, but would inspire the sharing of field and field-type definitions for reuse. 

Time and effort is required to publish this solution but it already works well.

Regards

Tony

[bimlas]

TonyM,

It looks like we have a similar solution, but yours is more sophisticated than mine. I only define the "field-type" field ("list" / "value"), a "template" field ("<<tag>>", "<$ link />") used to display and a "direction" field ("from" / "to"; if the field can be used to represent a hierarchy, "from" means that the tiddler itself marks its children as a "list" field, "to" means that the children mark the tiddler as their parents, eg . "tags" field).

Definition of "tags" field:

title: $:/config/fields/tags
field-type: list
direction: to
template: <<tag>>

Definition of "list" field

title: $:/config/fields/list
field-type: list
direction: from
template: <$link/>

Definition of "color" field:

title: $:/config/fields/color
template: <input type="color" value=<<currentTiddler>> disabled> <$view field="title"/>

 Either way, it is clear that defining fields is necessary to make them more flexible. I wonder what Jeremy thinks about that? It is certain that these ideas are feasible, but it is questionable whether they get into the core? If not, even though many plugins use this principle, each plugin needs to be configured with its own fields, since they do not use a common setting, but each has its own solution.

[bimlas]

PMario, 

 

The boot.js contains some "tiddlerfields" module definition, which allows special handling for different field types. 

Yes, that would be a solution, but in editable form (config tiddlers).

[Jeremy Ruston]

Hi Bimlas

As pmario points out, the special behaviour of the fields modified, created, tags, list and color is defined within the JavaScript core of TW5, and isn’t directly accessible from wikitext. It was clear some time ago that this approach isn’t optimal, but by then it was too late to change it.

We could perhaps ameliorate the problem by exposing that JS configuration information for wikitext to access.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7b2e63b3-0636-451f-b9f5-1a79ffcb1ad7%40googlegroups.com.

[bimlas]

Jeremy,

We could perhaps ameliorate the problem by exposing that JS configuration information for wikitext to access.

I think that besides being able to read these settings, they should be adjustable. For example, if I want to use a custom macro instead of "<<tag>>", which can open all tiddlers, I simply replace the template in the "tags" field definition with a macro I want. 

[TonyM]

I think that besides being able to read these settings, they should be adjustable. For example, if I want to use a custom macro instead of "<<tag>>", which can open all tiddlers, I simply replace the template in the "tags" field definition with a macro I want. 

Bimlas, 

Actually this macro needs to handle edit and view mode (ideally others)  and be applied to some tiddlers not others. Personally I think we could keep the edit and view templates but allow a third (or more) template(s) that permits in tiddler edit by mode and references alternative handling. Keep in mind we may often need to revert to a simple edit, or view especially to repair an error in a tiddler that is not displaying an edit method.

Regards

Tony

[Mark S.]

Wouldn't this greatly increase overhead? In TW, each tiddler has it's own collection of fields, and those fields may be used independently of any other tiddler.

So "mylist" in one tiddler might be a standard title list field, but in another tiddler it might be a CSV list of work contacts Joe,John,Joanna ...

Having to include all that meta data for every tiddler would bloat TW even more, which already has ~100 bytes of overhead per tiddler.

If you mean just for key fields like "list", I think anyone who had read the documentation to find out the meaning of "field-type" would also have already read the documentation to find out that "list" is a special field. So the ultimate answer would be to make the documentation more engaging.

Thanks!

[Jeremy Ruston]

Hi Bimlas

I think that besides being able to read these settings, they should be adjustable. For example, if I want to use a custom macro instead of "<<tag>>", which can open all tiddlers, I simply replace the template in the "tags" field definition with a macro I want. 

It sounds like you’re talking about a default view/edit template for each field. That’s not what we currently have: the field data in the boot kernel is concerned with how field values are parsed: as lists, dates or colours.

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/71c2b948-ed22-46a1-9af0-8fd489ae0796%40googlegroups.com.

[Thomas Elmiger]

Hi bimlas,

Regarding your example:

For example, if I want to use a custom macro instead of "<<tag>>", which can open all tiddlers, I simply replace the template in the "tags" field definition with a macro I want. 

I once made a plugin to get my own template working with tags ... took me 8 tiddlers plus config/docs. (Link)

So I would support any idea to improve the hackability of (special) fields.

All the best,

Thomas

[bimlas]

MarkS,

I understand what you mean and you are right that the same field may contain completely different data. 

Having to include all that meta data for every tiddler would bloat TW even more, which already has ~100 bytes of overhead per tiddler.

I imagine the template is optional: for example, it would be defined for the "tags" (<<tag>>) field and also for the "links" (<$link/>), but for example the "description" field would not need a definition, it would appear as plain text. The user would have the option of defining a template for the fields that are important and uniformly managed (for example, if you made a family tree wiki, the "gender" field could get a template that contains the gender icon).

If you mean just for key fields like "list", I think anyone who had read the documentation to find out the meaning of "field-type" would also have already read the documentation to find out that "list" is a special field. So the ultimate answer would be to make the documentation more engaging.

And what if you want to use additional fields like the list? A list for the software platforms (even a template with an operating system icon), another list for programming languages, and a third for categories. What's nice about TiddlyWiki is that you can implement your own ideas because it's extremely flexible, you can hack nearly everything. "Fields are first class citizens" - why shouldn't they be treated flexibly?

[TonyM]

Mark et al,

Field definitions field-types and  macros can provision sophisticated by easy to use field without any core change or the use of Javascript. We already have all the tools available in tiddlywiki, I am building my own solution but a community developed defacto standard would have great benefits.

Fields by definition tend to have the same meaning across multiple tiddlers, but in the case of the list field if defined to handle lists of titles it can be used as desired as long as it lists titles, what those titles are is of course the value/data. I would suggest leaving the list field to the tag order process already built in and defining another field to list other titles. Using the field-type abstraction the existence of one list field and its definition would allow the quick application of the "list" field-type to any other field. Encouraging users/designers to create a new field when it has a functionally different purpose is good coding, and making a set of field-types for existing and common field types, allows reuse with little if any extra code. 

For example Whilst working on my business solution I generated the following field-types 

• Many are custom but many reusable. 
• If we had a standard field/field-type definition these could be shared for reuse
• Less field-types are needed than defined below because I built more generic field-types

$:/landscape/field-types/area-manager

$:/landscape/field-types/caption

$:/landscape/field-types/consultants-list

$:/landscape/field-types/country

$:/landscape/field-types/discipline

$:/landscape/field-types/email-address

$:/landscape/field-types/false-or-true

$:/landscape/field-types/false-true

$:/landscape/field-types/field-type

$:/landscape/field-types/filtered-list

$:/landscape/field-types/filtered-list-linked

$:/landscape/field-types/first-name

$:/landscape/field-types/gender

$:/landscape/field-types/hyperlink

$:/landscape/field-types/list-columns

$:/landscape/field-types/management-consultants-list

$:/landscape/field-types/medebridge-location

$:/landscape/field-types/medebridge-postcode

$:/landscape/field-types/membership-and-order

$:/landscape/field-types/middle-names

$:/landscape/field-types/object-type

$:/landscape/field-types/office

$:/landscape/field-types/office-address

$:/landscape/field-types/office-area-manager

$:/landscape/field-types/office-consultants-list

$:/landscape/field-types/office-job-code

$:/landscape/field-types/office-list

$:/landscape/field-types/office-orams-code

$:/landscape/field-types/office-orams-location

$:/landscape/field-types/office-orams-postcode

$:/landscape/field-types/office-orams-service

$:/landscape/field-types/office-permanent

$:/landscape/field-types/office-postcode-description

$:/landscape/field-types/office-postcodes

$:/landscape/field-types/office-region

$:/landscape/field-types/office-state

$:/landscape/field-types/optional-text

$:/landscape/field-types/person

$:/landscape/field-types/person-role

$:/landscape/field-types/person-services-list

$:/landscape/field-types/phone-number

$:/landscape/field-types/primary-office

$:/landscape/field-types/referrers-list

$:/landscape/field-types/registration-type

$:/landscape/field-types/secondary-discipline

$:/landscape/field-types/select-with-field-values-filter

$:/landscape/field-types/select-with-values-filter

$:/landscape/field-types/services-list

$:/landscape/field-types/short-text

$:/landscape/field-types/state

$:/landscape/field-types/state-cover-office

$:/landscape/field-types/state-cover-panel-type

$:/landscape/field-types/state-cover-sira-approval

$:/landscape/field-types/surname

$:/landscape/field-types/text

$:/landscape/field-types/text-area

$:/landscape/field-types/text-data-existing

$:/landscape/field-types/text-existing

$:/landscape/field-types/text-line

$:/landscape/field-types/text-size-40

$:/landscape/field-types/title

$:/landscape/field-types/true-or-false

$:/landscape/field-types/true-or-false-show

$:/landscape/field-types/wikitext

$:/landscape/field-types/year

$:/landscape/field-types/yes-or-no

$:/landscape/field-typeTiddlerView

Regards

Tony

[TonyM]

Folks,

I believe it is in a case like this, where we are trying to push a little more sophistication into tiddlywiki where the use of Google Groups starts to show its limitations.

Perhaps some kind of online hangout where we can present and review each others approaches and increase collaboration would make sense.

Regards

Tony

[PMario]

On Monday, January 6, 2020 at 4:54:30 PM UTC+1, Mark S. wrote:

Wouldn't this greatly increase overhead? In TW, each tiddler has it's own collection of fields, and those fields may be used independently of any other tiddler.

I don't think so. From my point of view, it would only need 1 config tiddler per field. IMO for consistency reasons.

 

So "mylist" in one tiddler might be a standard title list field, but in another tiddler it might be a CSV list of work contacts Joe,John,Joanna ...

I think mylist can only have 1 type, to be consistent and avoid the overhead. ... But you are right. it may cause "name clashes" between content from different users.

 

If you mean just for key fields like "list", I think anyone who had read the documentation to find out the meaning of "field-type" would also have already read the documentation to find out that "list" is a special field. So the ultimate answer would be to make the documentation more engaging.

I think the goal should be,  to make "list-like" behaviour, that is baked into the core atm, more usable for end-users.

-m