Thanks @Springer some very important issues you have raised on the next step of the field-type. Which we have not discussed as much so far, but clearly you have investigated this to a substantial extent.
- In particular the alternative types of list field is importiant amongst more in your reply.
Yes, this is why I hope we can soon share a framework on which we can build field-types.
I feel we have three more key issues to address that are importiant to an open and forward looking platform on which the community can thrive. All three influence how field-types can be implemented.
- The ability to have tiddlers be qualified so that fields can be defined differently for different sets of fields. tiddler-type perhaps?
- Custom fields at least need view and edit modes, so as we implement this we may as well allow two or more modes, for example “update” mode may be when you can modify a field when viewing it by clicking on a field edit button, and read-only does not give you these options.
- A field or field-type system will need to take account of these modes
- The provision of a standard macro or widget, so it is trivial to make use of fields and retrive the nessasary tiddler-type, field definitions, field-type and mode responce. Then display or edit the field in the user interface. I have done something similar in the past but want to socialise it with you and others interested.
- Later we can use the above to prepare forms, create new tiddlers and fields.
More on the first item above tiddler-type
As has being discussed elsewhere tiddlywiki has reserved the type field for its own core operation and different mime types. Thus we can’t use this to differentiate between different tiddlers which will have different field sets and field definitions. We need to find an aggreed way to do this, because people can build their own sharable solution with their own tiddler-type/s
- Allthough it may be safer to consider implementing a “roles” approach where tiddlers can have one or more roles at one time. I have just done a Proof of Concept on this but for missing/tag/field/and flag tiddlers.
Why tiddler-type now?
A simple use of tiddlywiki will result in field definitions based directly on a fieldname that are shared throughout the wiki.
However sometimes users may want a different definition for the same field or fields. This would be hard to retrofit, but simple to add now. We just need an aggreement. But do read though section this before commiting to this.
- A field defined from a tiddler without a tiddler-type may use the tiddler fieldname,
- A field defined from a tiddler with a tiddler-type will use that to construct a field definition in tiddler-type/fieldname.
- thus the same fieldname can be defined different ways for different tiddler-types.
- An optional prefix of “$:/” could use “$:/tiddler-type/” to prefix field definitions only for that tiddler-type
- For safetly if a tiddler-type is in use but field definition is found at $:/tiddler-type/fieldname then fall back to fieldname. So custom tiddler-type or roles can still use standard field definitions.
I propose that tiddlers have a tiddler-type field that defines the primary role of the tiddler, we could call it the first role. Then we can make use of the roles or tiddler-roles field in future, so tiddlers can have multiple roles. A common extra role may be as a todo item, to do something on the current tiddler-type instance.
- We need to simlify the use of a list field like the roles/tiddler roles so that rolls are added to the tiddler not replacing any existing ones.
Yes, nothing is new 