These names are mostly for database tables tiddlers, and they can be set by human beings or by machine code. A basis is that I append would-be table names to get tiddlers names, an from them I get the name for operative tiddlers that do the CRUD for them. In effect, the CRUD operations are all centralized within a single tiddler for each kind of data sub-table – of course there are specialized tiddlers for doing the actual operations – think of it as a master/detail relationship.
First I start with a project name, which is free but with constraints such as only lower letters and digits and eventually a point within digits (for version number) and starting with a letter. The same for the tables of projects with also no digits for it. My project tables is called projets and let’s say there is a foo project. The tiddlers for projets CRUD is PTF_projets (PTF as portefeuille de projets). Since it’s an important starting point, I avoid such an horrible name by crating a “portefeuille des projets” tiddles whose sole content is {{PTF_projets}}}.
Actually, the projets table is not stored in a projets tiddler but as a system tiddler in $:/user/eva/data/projets (eva being the name of the app and I store all my user-written system tiddlers within $:/user/). I use a system tiddlers for all database tiddlers to avoid it being pouring continuous change in the recent history (it was obliterating everything else and ho interest).
Each database table is a json tiddlers. I have not metadata associated with it beside a few fields such as to tell its purpose for instance. That can be used to generate some listing tiddlers with macros.
A project has campaign. These correspond to a table that would be named cmp. But I have not one huge table for all the campaigns of all the projects as I would in a real database. That would no be very clever within tiddlywiki. Instead I have one sub-table tiddler for all the campaigns of any given project. As for its name, just give an example : for the foo project,its campaign are in the foo_cmp tiddler (cmp for campaign). It would be bar_cmp for the bar project. And the CRUD tiddler for foo_cmp is CMP_foo_cmp (and the CRUD tiddlers are not system tiddlers because it’s useful to be able to look for them and know if they are updated as I develop the application). CMP is just the upper case of cmp and this is the rule: the CRUD tiddler for *_something is always SOMETHING_*_something but I try to limit something to 3 to 5 letters.
Below campaigns are tests, which are in a tiddler named foo_cmp_tst for the foo project and CRUDed with tiddler TST_foo_cmp_tst (tst for test).
This naming leads to may CRUD tiddlers. But each such tiddlers only transclude a template tiddler like $:/user/eva/templates/CMP_Template for the CMP template or $:/user/eva/templates/TST_Template for the TST template. There is no nesting for template names as you can see.
And within my json tables, I don’t use the default structure provided by tiddlywiki for arrays of objects. Because I need to be able to identify each record for fetching/updating/deleting it and that is nos possible with a simple array. Instead, I use an array of key+value there each key is the value of the identifier and the value is the whole record, including the key (to be more able to repair problems if/when the data get corrupted).
For instance for the projets table, here is one possible full contents of the projets table with two projects, foo and bar, name being the name of the key:
[
"foo": {
"name": "foolish app",
"url": "http://foo.acmeserver.com",
"project": "Foo"
},
"bar": {
"name": "bar",
"url": "https://barometer.acmedev.com/app/",
"project": "barometer of ACME projects"
}
]
This naming is heavy but essential as the name allows to know the place and the function of any given tiddlers that is so named. It has proven to be hugely helpful!
I think it would be cool if my json convention for arrays could be natively supported. I had to develop some dedicated code to manage my tables (that I could share).
Back to the CRUD. As I said, there are specialized tiddlers that do each task of crud (one for input of key value, one for editing fields (but for key!), eventually one for deleting) their names are free, but all of them has only one line of text like {{$:/user/eva/forms/campaignEditor}} which point to the actual tiddlers whose name follon stricter rules: they are in $:/user/<project>/forms/and are name as <name-of-concept><name-of-operator>. The latter part being either CreatororEditororSuppressor. Each of these latter widgets like campaignEditor have some fields to help processing line a datasetone indicating on which data tiddlers it is operating,tempwhich indicate the name of the temporary data widget in which the data is really being edited. I really hate the default scheme when you edit without having to confirm your edit and cannot cancel them and it's not how one do in data managing apps so I have to copy data from dataset into temp and then wire the editing widgets with the temp. There is also a host field which indicate the name of the tiddler to be on display, for instanceCreation of a new campaign`for the $:/user/eva/forms/campaignEditor (you can see that each one in this relation know its peer) and this allow the programmer to indicate it want to operate an edition quite simply without having to worry if the name of the GUI tiddlers vary (thus, this functionality is OK for localization).
