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 On Tuesday, January 7, 2020 at 9:44:00 AM UTC+11, TonyM wrote: > > 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 > > > On Tuesday, January 7, 2020 at 2:54:30 AM UTC+11, 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. >> >> 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! >> >> >> On Saturday, January 4, 2020 at 11:58:47 AM UTC-8, 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6d8c454c-e98b-4828-a3bf-0c2615bce2eb%40googlegroups.com.
