I just want to support the clarity in your first post, and also you using field-description. Using this prefix field- for all field-related data tiddlers can similtaniously be tags, field and contain other content.
- Should the fieldname solution be “direct” or “indirect”?
- I think we should start with direct fieldname, but provide an option to migrate to $:/fields/fieldname if needed. The editor and other tools can be designed to look for $:/fields/fieldname first then fieldname. This allows us to use the system thus hidden form if the fieldname clashes with anything.
- Should users have fine-grained option to enable/disable “missing” fieldname links?
- On second reading I think this is a good idea, especialy when parsed in the text field. But we need a local overide for some cases where the fieldname is multifunction eg the tags field may also open the/a tags manager.
- Secondly we can have a more > fields tab to access them if disabled.
- What do you all think are the essential or most exciting fields about fields ?
I think the latitude to define a field even complex attributes through field- prefixed fields. Here are some I want;
- field-description what is it about
- field-caption eg description field may have
Descriptionsentence case - field-tooltip appears on mouse over
- field-values filter or list on what where to find values
- field-type - this would point to a shared field-type whic may describe how to edit or display a color field, email address, short text, numbers etc… there will be far fewer field-types than fields needing definition
- A field although it has a field-type may localy override a field-type-fieldname if it differs from a field-typ tiddler in some way, just by including that field-type-fieldname in a field tiddler.
- For full and comprehencive field handling we would need to discuss what exists within a field-type tiddler, even if they are the same tiddler.
- An important thing about field-types is they can be freely built and shared without use unless assigned to a field-tiddler.
- The items you raise such as is_textarea/is_list etc… are better handled in reusable field-type-fieldnames be they in the field tiddler or in a shared field-type-tiddler
In a related matter it is clear we can say use an arbitary field to indicate it is a field tiddler eg field-description but this is somewhat arbitary, and one needs to remember what it is. I have come to the conclusion we need a defacto standard of a tiddler-type where we can indicate it is a field-tiddler, field-type-tiddler and other forms like contact, bookmark, organisation, domain, project etc…
- However as discussed above one tiddler can quite easily have more than one role so perhaps tiddler-types (field) could be a list of roles, or we could use a tiddler-roles field?
- We may then simple add another role or type to the list to create a field tiddler. The view template can then add a panel to any tiddler found to have the field role (or other roles). Such pannels can be turned off globaly with $:/config/design-mode=no
- We can have a cascade option for loading the correct view template, body template(s) etc… for each role provisioned in advance, just use them as needed.