Si,
Good Question: I will have a go, but I expect time will help.
- One important note is I still intend to use the original limited field
names as I currently do, when I use fields that use the extended naming it
will be to make use of the possibilities.
- Of course this is needed for backward compatibility
- Interestingly I think, one way to make use of these freedoms is to be
able to develop new constraints, hopefully this will be clear later in this
reply.
- You can see that in simply replying to your question, I have being
able to explore the possibilities further than I have so far.
- Handled well it may prove to be revolutionary.
- I think there is an argument if not handled well some tiddlywiki
solutions could become unreadable
- Perhaps this could be used for some "security by obscurity" eg
encrypted fieldnames
*Tiddler names as fieldnames*
Possibly the most meaningful possibility is to create *fieldnames using a
tiddler name*, then being able to use the value of the field to store
information about the relationship between the two tiddlers
Eg lest say we have two tiddlers Alice and Bob lets say Alice is given a
field "Bob" containing the value "husband".
- Not only do we name the tiddler Bob to which Alice has a relationship,
but the nature of that relationship
- But it is simple to search all tiddlers containing a field called
"bob" to find what other tiddlers have a relationship with Bob
- You can see here the the relationship may be better named "spouse"
and you derive husband and wife from this.
- One thing you may notice is what if I was using the tiddler name as
fieldnames for other purposes, lets say Alice and Bob are both members of
the book club so this is where I am likely to use the fieldnames
differently.
*Compound fieldnames*
The freedom to use many different characters in fieldnames allows us to
make use of compound fieldnames, which I explain here, but you will see
that todo this successfully we have to in some ways need to reintroduce
constraints, or naming standards.
- For example if I apply an informal constraint on tiddler names that I
will not use colon in the tiddler title.
- I can then use ":" to delineate parts of fieldnames so to extend the
above example
- "relationship: spouse" value="Bob"
- or even " relationship: spouse: Bob" value="date of marriage"
- I can then search for fieldnames based on a prefix "relationship"
where we split on ":" then last[] will find the tiddlername "Bob"
- I can see how since : is in use in URLS, that may form titles It may
be better using a character that is not on a keyboard.
*Shorthand fieldnames*
Given fieldnames can use unicode symbols and other character sets rather
than use the simple standards I see value in using these as fieldnames
- eg ☎ phone, 📧 email address, or mobile 📱
- This means
- the meaning of the field is part of the fieldname
- only one character is required
- We can also use this to introduce custom fields with the same quality.
- 📧 = preferred email address
- "📧 Personal"
- "📧 Business"
*Field types*
You can see in the above example the prefix represents an email address.
This allows you to determine the value of that field needs to be a valid
email address. So you can effectively use this character to determine the
type of the field and determine how to display or edit any "email address".
- We could use special symbols but naming standards can also add meaning
to a fieldname; for example all fields ending with ":link" the prefix would
be a pretty link, the value the actual link
- eg fieldnamed "tiddlywiki.com :link" value="https://tiddlywiki.com";
- This could be important to define fields that are textareas or rich
text 🖺
*Field Lists*
You could do this in the current naming standards or within fields who's
values are a list but this would be easier to read/edit in some cases. For
example imagine a menu-tiddler with the following fieldnames
- ":menu-item :Top :01" value=<a target="_top"...
- ":menu-item :middle :02" value=[[Home]]
You can see in the above because the fieldname includes the pretty link Top
and middle that they will be unique but the addition of the number can
guarantee this and store the order.
*Guaranteed Plugin in or macro fieldnames*
I for one write a lot of macros and so use the names space of $:/PSaT/....
for my tiddler titles. We can now also uniquify fieldnames for example I
could prefix all fields used by a particular string that represents me as
the author eg PSaT.
*In closing*
I am sure more possibilities will arise than explored in this reply,
however I think it highlights the value in using such extended fieldnames
for purpose, and that the development of new naming standards applied on
top of such freedoms by the designer is likely to bare more fruit than "las
a faire" naming. It raises the need for a suit of tools to assist the
designer in making use of these features from Editor toolbar buttons,
advanced field lookups, tiddler to fieldname tool, to character selection
tools like https://qaz.wtf/u/convert.cgi but built into tiddlywiki.
Or https://unicode-table.com/en/ to use and enter symbols.
It would be interesting to discover what other solutions make use of
liberated fieldnames and what have they done!
Regards
Tones
On Sunday, 1 August 2021 at 02:09:37 UTC+10 Si wrote:
> As you are probably aware, the next release of TiddlyWiki will remove the
> current restriction on characters for field names (
> https://groups.google.com/g/tiddlywiki/c/kF-OGmkyFfo/m/dN-P0KRVBQAJ).
>
> I feel like this adds a lot of potential for new workflows, but don't have
> any particular ideas myself.
>
> *So I'm curious if there are users out there who plan to adapt their
> workflow, or introduce new workflows, as a result of this change?*
>
> *Do you plan to change the way that you name or use fields? If so how?*
>
--
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/d2eaf727-3ea7-4192-b5b1-05b7d694f65fn%40googlegroups.com.
