TW "Tiddler DB" Strategy

[Qalisto]

Hello, I am new to TW.

It seems, I should have discovered it long ago.  (I had been using an app for Windows called ConnectedText.  But, it lacks the killer feature of TW which is single HTML distribution.)

I have a question about the strategy for rational and flexible access to Tiddlers.

It seems to me that for Core Business interests that it may be wise to just create Tiddlers as "info Lego blocks" into a "Core Bus. TW" as Tiddler repository.

Then, by using the correct coding or Tagging strategy, to be able to extract a list of Tiddlers which one may wish to include in ... say "Project A" (while the same Tiddlers may *also* be employed in "Project B".

So, given the bewildering set of system, user, shadow Tiddlers, I am wondering if anyone more experienced has a system which will:

(1) Enable a single Tiddler to be coded in a way that will identify it as in the family of say "Project A" and also "Project B" if it is a common info bit.

(2) Hide that multi-project coding since I will want to compile the family of Tiddlers as a business presentation and leave the content "tidy"

(3) And be able to order the extracted Tiddlers from the Core TW File in the desired order of presentation

Of course creating an "NY Public Library" of Tiddlers may be unwise.  I don't know at what point a TW file becomes too fat and thus unwieldy. But, I plan to create distinct ones where possible.

There seems to be multiple solutions spread about various user URLs.  And I am sure I could divine this with hours of research and trial and error. 

I just wonder if someone has been where I want to go and can kindly share a shortcut.

Thanks for any help. ## Q ##

[Mark S.]

There are many ways to put things together in TW. It kind of depends on how monolithic the structure

you're attempting to create is.

Here's one way.

In terms of traditional relational databases, you can think of all tiddlers that have the same tag

as being rows in a table. The fields of each such tiddler are the fields of the "table". The title

should be thought of as an ID field, and not, unfortunately,as a title. Use "caption" and "description"

as the actual title fields.

Tag/Tables can form parent-child relations via reference fields. So you might have several items

tagged as "Project". Then you might have several tiddlers tagged as "Tasks". Each tiddler tagged

as "Task" can contain a reference back to the original project tiddler. For instance, you might

have a field "projid" that contains the name of the "parent" tiddler that is tagged with "Project".

Using nested list widgets, you can present the information in the Projects and child Tasks

much the way you would in various report tools.

Project A

   Task A1

   Task  A2

Project B

  Task B1

  Task B2

The display doesn't have to show the tags or the reference fields that are structuring the data.

There are other people that would tag each task with the "parent" tiddler, but that quickly leads to

tag pollution.

So, there's one approach. It really depends a lot on what you are trying to accomplish. I'm sure others

will chime in with their thoughts.

[Luis Gonzalez]

Notes:

• Usually a tiddler for the Project A is tagged with "Project A" tag.
• A tiddler for both projects is tagged with "Project A" and "Project B"
• To have a list of the tasks for Project A you will write {{{ [tag[Project A]] }}}. This is a filter, so you have to study filters.
  
• To sort the tasks of Project A create a tiddler, "Project A" and put the ordered list of tasks in the field "list" of this tiddler.
• Tiddlywiki can do this automatically with the widget list-links-draggable.
• Create a new tiddler, Project B and add this code:
!Tasks
{{{ [tag[Project B]] }}}

!Reorder tasks
<<list-links-draggable tiddler:"Project B">>
• At first the "Reorder tasks" will be empty. Drag a task of the top "Tasks" list under the "!Reorder tasks" to sort them. Add all tasks and sort them dragging them.
  
• Widgets are very powerful, you should check them.

[Qalisto]

Thank you Mark and Luis ... will employ "learning curve ops"

[Donald Coates]

I will try to make a list of some links but this is really the way to go.  I play dwarf fortress and have been working with TW and I have found working with fields to be extremely powerful and flexible.  There are a lot of widgets that allow you to work with info searched for in fields as well so I would suggest really concentrating your 'learning curve ops' by searching and reading about fields and the widgets that allow you to work with them.  Mark's explanation here is really spot on.

[TonyM]

Q,

I reread your origtinal post. If you want your sentral DB in TW to have a database that you export part of for another application I would recommend the field based approach of Marks however if you really want to export with even this field not in the export you can take two approaches,

• Develop a custom export process that does not include that field.
• Use another way to select tiddlers. A Button or select appearing on all tiddlers (using the view template) could allow you to add the currentTiddler to a datatiddler as a list. The export filter would them select all tiddlers in the data tiddler for export, so the organising list has nothing within the selected tiddlers, it sits to the side in the data tiddler. So for example you could have a tiddler projectname-tiddlers containing tiddlers belonging to that project name. The view template could also look up which projects the current tiddler is named in and display this only in your central tiddler.. 

The beauty of tiddlywiki is it can accommodate more database models than you could design.

Regards

Tony