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 On Sunday, January 5, 2020 at 6:58:47 AM UTC+11, 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 > > 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 > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/8bb56a01-bfa5-484c-9e53-ee495dcacb44%40googlegroups.com.
