The question would be how do you ?
Then if we can automate doing what you do.
Where will this come from if it were automatic?
Download the following and drag it to tiddlywiki.com (or to your backed-up wiki), and import the result:
prefillField.json (622 Bytes)
Then if you create/update a tiddler and add the field my-new-field you should see it prefill with Catalog/Avatars/. If you edit that value and save, you’re all set.
However there is a bug I don’t know how to deal with. If you don’t edit at all, the field will end up blank. Any editing is fine, even adding and then removing a space. I understand why this happens: the default is for the edit field and not for the underlying tiddler storage. But I don’t know how to fix it. I would love to hear from someone more experienced.
To fix it for your use-case, edit the two tiddlers, and change all instances of my-new-field, including in the titles, to your field name, and it might be close enough for you. Or perhaps not, but it might still be a start.
The Catalog/Avatars/ would ideally auto-populate in the field-value field, ready for me to paste in the creatoravatarpic.ext.
By Jove, @Scott_Sauyet, I think you’ve done it!
This indeed seems to work and do exactly what I’m needing.
I find the pic, save it to the folder, copying the filename to the clipboard, switch back to the Tiddler and add the avatar field, and my prefix Catalog/Avatars/ appears. Then I just Right-Arrow and paste the filename in, hit ‘Add’ and we’re done!
No worries about having to edit the field, as I do have to paste the filename in.
One strange thing: Instead of remaining at the bottom of the Tiddler, after I click ‘Add,’ I’m taken to the avatar field (second field from the top, first being author), which is fine, just unexpected.
I don’t really understand what’s going on behind the scenes with the json file, but it’s very easy to edit it to change field name and output, so I’ll definitely keep it around for any future situations such as this!
Thank You so much! 
One small niggle, @Scott_Sauyet: Now, whenever I edit any tiddler with the avatar field present, the initial focus is on that field, instead of the title field, as usual…
I see in the json file there’s a focus=\"yes\" - I know that’s needed to do what I want this to do, so if it’s something that would be hard to fix, I can certainly live with it for the time being.
I won’t be keeping this in the wiki after I finish adding all the avatar pics (I have a ‘template’ tiddler that I copy for each New entry, and it has all my default fields in it, already populated with the necessary values).
This version takes out the focus property and adds a tabindex. It also changes the name of your field from my-new-field to avatar, which sounds like what you are using.
It might correct the issues you see. Remember to backup, and probably delete the tiddlers added before… although this might automatically overwrite them.
prefillField2.json (620 Bytes)
If I find some time (maybe tomorrow, definitely not today) I’ll try to write up an explanation.
I just finished editing the last remaining tiddler needing an avatar pic - The ‘job’ is finished!
Thank You, again, to @Scott_Sauyet, @TW_Tones, and everyone else who offered help and suggestions to my dilemma
I’ll say again that I really think this functionality (having a drop-down on the field-value field listing all the previously-used values in the TW) should be included in the core.
I could be totally wrong, but it seems to me that if it’s possible to have it for the field-name field, it should also be possible for the field-value field…
Maybe someday, @jeremyruston?
- I have done this in the past but it was not easy to share, I did it using the field editor cascade
- Note: it is not suitable for some fields
- I used the
each[feldname]get[fieldname]operators
I will eventualy share this in a set of other field value tools, but it needs some “wrap around” de facro standards.
@TW_Tones: Would love to see it when you get it ‘polished’ enough
I never noticed its absence until I started this current project, then it seemed to stick out like a sore thumb.
If there’s a rationale to having the feature on the field-name box (and there certainly is – it’s indispensable to prevent you from having to type a previously-used field name every time you need to use it), then logic dictates that it would be equally useful on the field-value field.
Perhaps it wouldn’t be that useful for small wiki’s that have few field values, but in a large, field-heavy TW (such as the one I’m working with right now), it would make life SO much easier
While I have your ‘ear,’ let me ask: Would the size (total number of characters) of the field value make any difference in having the feature?
The reason I ask is that I have some fields in this wiki that are insanely huge, I mean many thousands of characters; I have fields in each tiddler that render large chunks of the text content of the tiddler.
Now, granted, I would never need to use the drop down on those fields, as their content would be too specific to their original tiddler to be re-used in another one, but I’m wondering if it might cause some sort of ‘data overflow’ should the user have such a large field and (accidentally or on purpose) use the drop-down?
Perhaps it could be character-limited to only show, say, the first 30 or 40 characters of the field – that would keep it ‘safe.’
This did not seem importiant to me as we start typying we can select from the names that popup, however it should be easy to at least provide this the most recently used fieldnames, or from a set of most used fields or a configurable list.
Actualy it can, because the values can be from a preconfigurd set, in effect documenting the suggested values for a field. It kind of documents the field, being able to see the suggested values.
Well, it will impact the usability of it for sure, and yes you can have it display only the first 80 characters or so in the selection list. However I would suggest perhaps in this case it may be better to make a bespoke set of tools, allow a search method to select from different values, instead saved in actual tiddlers perhaps.
Most likely not an error, just an unpeasent look.
- If that is the case we just need a flag to not show the dropdown.
- If you create a tiddler
$:/config/EditTemplateFields/Visibility/fieldnameand set its contents to hide,fieldnamewill no longer appear in the field editor. You can then introduce a different editor tiddler using the $:/tags/EditTemplate tag.
Some of the ideas/issues you raise here, is in fact illustrating part of my delay to publish a final solution, the ideal way to handle it is to have a field definition, and since many fields are defined the same way, have a set of field type definitions, eg data, color, text, numbers, list, existing values, from title search ecetera excetera…
- Such a solution would be best if it can be invoked from a body cascade, story cascade or the view template as well, in addition to the editor field area.
- But then we dont need to define such fields if they are rearly used, just use the default editor(s)