Folks, I have constructed various fieldnames over the years that make use of naming standards such as menu-item1 menu-item2 or link/named-link/another-link where my code can find all fields on the current tiddler or throughout the wiki say with the suffix "-link" and then determines the prefix and returns that as a value eg; the link "another" containing the url found in another-link.
In the above cases you can see the hyphen acting as a delimiter, with the lifting of naming restrictions on fieldnames I can see being able to use other delimiters such as : or even :link, I really like this freedom, but also wonder if we should preempt such flexibility with some de facto standards that we tend to use, eg in the above "link" is naming a field "type" in the name of the field. fieldname:link and we use link to identify how to display that fieldname eg; inside a html <a> element. I am also keen to have a de facto standard so we can build index tables in tiddlers for one to one, one to many or many to many relationships. For example fieldname:indextiddlername where the value(s) in such a field is a key to an index tiddler "indextiddlername" that contains one (or more) entries for that key, the entries may be values or "other tidder" names (other keys). The "other tiddlers" could also access the index. Although these structures can be already emulated in tiddlywiki with such de facto standards we can build sharable tools to support such sophisticated relationships. Do it once share and reuse many times. With carful use such structures could help with the performance of tiddlywiki when building larger and more sophisticated relationships/databases, while in a way stepping to the side of the tiddler refresh cycle. Regards Tones On Friday, 18 June 2021 at 02:30:27 UTC+10 springer wrote: > Jeremy and all, > > I too am *very* excited about this, especially given my dependence on > dynamic tables. > > First, a small confession: I've already been using short special-character > fieldnames for a while, sneaking around the protection by setting them up > as column names in Shiraz dynamic tables, and then editing those tables. > One use: column headings like ยง and @ that allow for compact and intuitive > presentation, when the column data tends to be single-digit. But this is a > superficial cheat (since these have been old-fashioned property-like > fields). > > More importantly, isn't this v5.2.0 step a path to more powerful > (multi-dimensional) relational data, or at least virtual pivot-table > behavior? > > Suppose a use-case that involves spread-sheet-like relation between > tiddlers (rows) and fields (columns), where the field-names tend to have > their own tiddlers (which until now we've named in the constrained way).... > > Starting wth v5.2.0, can't field names can serve better as the > intersection (cell) of these two dimensions? Values at the intersection > should be more readily accessed via either axis of the table, so that what > appears in Tiddler A, field F, also *could* be referenced easily within > tiddler F (That is, F can be set up with filters to draw info from all > tiddlers that use F as a field name). > > I imagine the intersectional-field-data housed remotely (on the other > "axis") could be rendered like virtual fields (within a filter-condition > ViewTemplate)... and it may even be possible to reach through and edit the > remote intersection-field directly. > > For true pivot-table purposes, a plugin could flag or help correct > discrepancies between A's F-value and F's A-value, no?Obviously, this would > have to be an optional feature, or one that hangs on some further > condition, since some uses might call for A's F-value to differ from F's > A-value -- especially on legacy projects built without intersectional power > in mind. > > I welcome corrections or clarifications from those who actually understand > the guts of TW5! > > -Springer > On Thursday, June 17, 2021 at 5:54:02 AM UTC-4 jeremy...@gmail.com wrote: > >> One thing to bear in mind is that the core has always supported >> unrestricted fieldnames for almost all operations. The primary thing that's >> changing now is that the switch to the JSON store area allows us to >> guarantee that arbitrary fieldnames will be respected over a >> save-and-reload cycle. The secondary thing is the removal of the very weak >> protections against creating fieldnames containing arbitrary characters. >> >> Perhaps there a relatively small number of usecases for complex >> fieldnames, but some of those use cases are powerful and so seem important. >> But even in the absence of important use cases, a very important benefit is >> that unrestricted fieldnames make TiddlyWiki significantly simpler to >> explain. Every little arbitrary restriction or caveat adds to the >> conceptual load for people learning TiddlyWiki. >> >> For me, one of the most important consequences is that we can encode >> variable name/value pairs as fields. For example, in the new publishing >> framework that is under development we represent a publishing job as a >> configuration tiddler that specifies the template to be used, the filter >> identifying the tiddlers to be output, and a collection of variables to be >> provided to the rendering. The variables are expressed as fields named >> "var-foo", where "foo" is the name of the variable, and the field value is >> the value for the variable. >> >> It's a simple and flexible approach that wouldn't be possible without >> loosening the restrictions on field names. >> >> Best wishes >> >> Jeremy >> >> -- >> Jeremy Ruston >> jer...@jermolene.com >> https://jermolene.com >> >> On 17 Jun 2021, at 10:42, Mohammad Rahmani <mohammad...@gmail.com> wrote: >> >> Like Mario, for me it is not clear what will be the benefit to have such >> liberty in naming fields! >> I think Tiddlywiki is growing organically! Sometimes you need to see good >> and consistent logic to be able to write better code to understand and >> maintain! >> So, while I am not against the new feature in TW 5.2.0 but I really like >> it, we are going toward a more consistent, easier to learn and easier to >> maintain grammar and syntax! >> >> >> >> Best wishes >> Mohammad >> >> >> On Thu, Jun 17, 2021 at 11:27 AM PMario <pmar...@gmail.com> wrote: >> >>> Let me be more specific eg: >>> >>> >So, the field values could be a relationship between the current >>> tiddler and those other tiddlers. For example: >>> > >>> >title: Adam >>> >Barbara:mother >>> >Caesar:father >>> >David:friend >>> >>> You mentioned that having upper-case letters in the field names can help >>> to solve the "relationship problem". .. >>> >>> I ask: Where is the difference from a setting below and your suggestion? >>> >>> title: adam >>> barbara: mother >>> caesar: father >>> david: friend >>> >>> There is no difference. The setting in the example has been there since >>> v5.1.0 .. and the problem isn't solved. ... >>> So as I wrote: Having more possibilities in the field names won't solve >>> anything. Sorry. >>> >>> -mario >>> >>> -- >>> 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+...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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+...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/3464d8e9-270d-4407-abf9-b5201b298dd5n%40googlegroups.com.
