Si/Folks, With just a few minutes research on unrestricted fieldnames another revolutionary possibility becomes apparent. Compound fields (not fieldnames).
The value follows the semi-colon : in this example address: title name add1 add2 city state post-code address title: Mr address name: Anthony Muscio address add1: NFP address add2: NFP address city: Kareela address state: NSW address post-code: 2232 This would allow you to programmatically bring all address fields together as an "address", you could add a new element for a one off special case or use this to present the form to enter the address. Regards Tones On Sunday, 1 August 2021 at 10:00:12 UTC+10 TW Tones wrote: > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b21862d2-52a7-4711-8b0c-52ff9177d7e3n%40googlegroups.com.
