Data Tiddlers and the Select Widget

Okay I am trying to create a reference data tiddler that will contain all the genealogy data of a particular person . . . a K.I.S.S. output at least for now. One crisis at time.

So I my goals are to create new data tiddlers and either create a new field/data or select a field ( from a list ) / data and adding that to the data tiddler. That I can do.

The problem I’m having is in creating the file or selecting the file to add the information to. I tried some of tricks I managed to figure out in previous versions, but I am not getting the same results in the current version.

Obviously I am doing something wrong ( or maybe multiple somethings ) and would appreciate any productive guidance on this matter.

Thanks.

Hi,
You need to be a bit more specific about your structure. We can’t help you if we don’t know how the connections should look like.

Just describe the data and the connections in plain English. Tell us what you want to achieve in more detail

sorry, I was being general . . . hopefully this overview will be more useful. This is currently what is working for me. The field editing I got from Scripts in Tiddlywiki :grinning:

DEFINE temp
DEFINE DataTitle
DEFINE DataSource

SET Names ( Family, Given, Middle ) *\\defines the tiddler name, ordered for filing purposes\\*

<CLEAR>

name your file

Family :  [  ]  Given : [  ] Middle : [  ]  *//it works, but there focusing issue even though it is the same edit-text structure as below ( which do not have that issue ); putting these fields in separate tiddler did not help. just been cut-n-pasting, okay for new but inefficient for updating files.//*

Using existing entries . . .

Index :  [ * SELECT * ]  *//from a defined data tiddler//*

Index ( new } : [        ]   *//in case field is not established yet, not only adding the standard stuff but items in found various papers ( residences, occupations, witnesses, etc. )//*

Value :  [       ]

<Add new index/value>

Sources  *//fields are the same but write to a different file//*

Index :  [ * SELECT * ]

Index ( new } : [        ]

Value :  [       ] *// textarea //*

< Add new source>

That seems to be pseudo-code from some other language/realm.

People that are new to TW often gravitate to data tiddlers, assuming them to be the core method of data storage. But this is not the case. Data tiddlers are an after thought – they are not meant for heavy duty data processing. They are good for when you have A → B lookup lists, but not much else.

The real unit of storage in TW is the tiddler . Your applications or usages should center on how to use tiddlers, not how to use data tiddlers. There are very few filter operators for data tiddlers. But there are many for tiddlers.

That is, if you have a tiddler about contacts, you might have each contact tiddler tagged as Contact . Then inside the tiddler you would have fields for first family, given, middle. You can then set up your own tiddler for creating new Contact tiddlers, which will help you populate fields as you need.

Just in case it helps;

You say “file” here but do you mean “tiddler or title”?

When you use ## ActionSetFieldWidget to set either a field or index it will create the tiddler silently.

The select widget can also refer to fields or indexes and has an actions parameter.

Mark I agree with you in general, good response.

However data tiddlers are also a way to build or store lists or conceal information from the search. The specific kind of JSON that can store tiddlers along with the plugin format effectively uses the JSON data tiddler and are thus essential.

Despite my wanting to promote the value of data tiddlers, It is true that experience will help identify when and if to use them but new users should avoid them and make use of tiddler titles as the key to data entries and fields therein.

{ * sigh * } Sorry it is not any code just an overview or mapping of what I currently have. I thought showing the script would akin to showing crayon drawing to a graphic artist. That being said, you shouldn’t assume I am new to TW. I am using data tiddlers as they fit the process I’m using to compile large amounts data quickly and with the possible need to show that raw data to someone or do a quick edit on the fly. What drew me to TW ( like version 2.6.2 or there abouts ) was it’s portability and versatility, tiddlers and data tiddlers are both aspects of those functions.

This is going to more than just a contact list or phone . . .

“create a reference data tiddler that will contain all the genealogy data of a particular person”

So that means birth, baptism, death, burial at the very least. Also parents, children, spouses. Details I pull up from Ancestry or FamilySearch : military records, census records, birth records, death records, probate, etc. It’s a genealogy thing.

both. the created tiddler and the ability pull up that tiddler to update the tiddler.

There may be few of us on the data tiddler band-waggon, but you are preaching to the choir.

Although in the very small minority, I often find data tiddlers fitting my purposes more so than fields. Although TiddlyWiki seemingly does treat data tiddlers as second-class citizens (or ugly ducklings), I’ve found the extra effort sometimes needed to use data tiddlers far outweighed by the benefits in certain circumstances (which vary significantly).

For general-purpose (newbies in particular), fields are a much easier and safer bet.

For those of us who need a little je-ne-sais-quoi that turns into a right mess using fields, data tiddlers can be some useful.

I do wish data tiddlers were first-class citizens to smoothen out some rough spots, but the workarounds aren’t horrible.

Hello @manhamster, I’m not really clear on the specifics of your question other than it involves data tiddlers…

I am pretty curious what used to work and doesn’t now. If there was a change in functionality in that area, I must have missed it.

Does “file” refer to a data tiddler? If so, @TW_Tones’s mention of action-setfield is what you want (and he included a link). While I’m a BIG fan of datatiddlers, as you may know that they only allow you to store essentially 1 field of data in it. I’ve forced the issue in the past and used my 1 field as multiple by storing data in there with delimiters. So like value-a::value-b:: and then handled extracting back out the individual fields on the back end after I’ve retrieved the value, usually using some split[] or regex stuff. This mechanism is kind of nuts, but can still be good if you ONLY need to look things up by that KEY value.

If you want to push even further, you’ll need a way to look stuff by their VALUE. That’s ugly in base TiddlyWiki as you’d have to loop through every value and test. Luckily @pmario put together one of my favorite plugins - KeyValues — advanced data-tiddler functions (wikilabs.github.io) that’s very helpful here.

Hope that helps,

Ah @manhamster - I’m re-reading and somehow missed your reference to <$select> as a mechanism. As I said in my above post, the limitation of data-tiddlers to only store one value means this will be rather complicated if your intent is to have multiple values compressed into the one. Not impossible, but complicated.

Actually, I should mention that the OTHER way around the 1-field limitation is (I’m cheating here) to have multiple data tiddlers - 1 for each column you want to store, with a shared key to kind of virtually link between them.

So like have one for Birthday:

KEY          VALUE
JOHN-SMITH | 1990-01-01
JOHN-BLACK | 1980-01-01
JANE-DOE   | 1970-01-01

And then have another one for the next thing like spouse

KEY          VALUE
JOHN-SMITH | BETTY SMITH
JOHN-BLACK | SUSAN BLACK
JANE-DOE   | TOM DOE

What do you mean can only store one value?

All along, I was thinking “Data Tiddler” as in “JSONTiddler.” I use these tiddlers to store multiple field values in the same way somebody would keep values in a tiddler’s fields.

Was the discussion always about “Data Tiddler” as in “DictionaryTiddlers?”

Okay I think everyone is getting sidetracked on minutia. Set aside the tiddler/data tiddler argument, it is not really relevant at this particular point.

Please reference the earlier mapping. All references to “file” means tiddler, file is just easier to type.

Trouble is the point where the title/file is created.

the text boxes keep losing focus, even though I am using the same edit-text structure. Transcusion from another tiddler does not help.

  • the issue seems to involve the SET statements, when i cut out the set statements the inputs don’t have that issue. Why is this? Is there a workaround for this issue?

the next issue is creating a select widget showing already existing files, allowing the file to be updated without removing all the info in the file.

Ah, fair point @Charlie_Veniot , my bad. Never used JSON for this purpose.

Oh heck no, @stobot, no bad at all. There are two data tiddler formats, and there was no explicit reference to either.

I think figured it out, though not doing both operations on the same tiddler. Though the Detail macro should be workable work-around.

Reference my mapping I just shifted the set/vars statement below the input used to create the tiddler name. Fixed the focusing issue and didn’t cause issues with input boxes below it. Maybe someone with better scripting skills can give a breakdown and rules on thumb for that.

For the updating . . . well turned out I needed to just define a field in my temp for the selectwidget selection to go to, and make sure the setfield and vars references this.