> 1. Data-centric Design > > I see a lot of discussions here about how to include parts from > multiple tiddlers, how to loop through tiddlers, and how to produce > lists and tables. It seems that people want to work not just with > text, but with data. The solutions typically involve starting with > regular text, and trying to turn it into data. > > I would build the core of TW around a javascript based database
You can think of the TWCore 'store' object as a simple, single-table database, where each record is a tiddler. By default, tiddler "records" contain standard fields: title text tags creator created modifier modified title, text, creator, and modified are all text strings. created and modified are date values. tags is an array of text strings. In addition to these standard fields, you can define *custom tiddler fields* that contain text strings. First, modify the EditTemplate to add a statement like: <span class='editor' macro='edit myfieldname'></span> This adds a new input field that appears when you edit a tiddler. Text entered there will be stored in the 'myfieldname' field of the tiddler. To display the stored value when viewing a tiddler, modify the ViewTemplate to add: <span macro='view myfieldname'></span> Of course, this assumes that the custom field is applied to *all* tiddlers in the document, since all tiddlers use the same ViewTemplate/ EditTemplate definition. One way to provide 'typed' tiddlers, is to use http://www.TiddlyTools.com/#TaggedTemplateTweak which provides several methods of identifying tiddlers by "type" so that they can use alternative ViewTemplate/EditTemplate pairs that have different custom fields, depending upon the type. Thus, TaggedTemplateTweak allows you to effectively "segment" the TWCore 'store' so that, even though it is a single-table database, you can query the tiddler table to extract a subset of tiddlers, based on the desired type, and then act on those tiddlers. You can use the TWcore <<list>> macro to generate simple lists of tiddlers with basic tag matching, or you can use something like: http://www.TiddlyTools.com/#MatchTagsPlugin to use full Boolean-logic expressions to select tiddlers by complex combinations of tags. You can also use plugins like: http://tiddlywiki.abego-software.de/#ForEachTiddlerPlugin which provides a looping 'harness' around custom snippets of javascript code. Many people have used this plugin to create extensive dynamically-generated tables of information culled from other tiddlers. For more advanced users (or those requiring full programming logic), you can use http://www.TiddlyTools.com/#InlineJavascriptPlugin to embed javascript code directly into tiddler content. These scripts have full access to the TWCore functions, and can fetch tiddlers using any process or criteria you want and then generate output based on the data retrieved. > 2. Saving Options > I would create as much flexibility as possible for how a tiddly > document is saved. In addition to the default local file solution, a > standard API would be available for interacting with a server backend. > I wouldn't actually create server software, but this API would allow > for a variety of server solutions to be created. There *is* such a mechanism in the TWCore! They are called "server adaptors", and the default handling for *local* files is support by a default "file" adaptor. Look for "AdaptorBase" in the TW source code. > 3. Hierarchy Support > > Many people like to organize their tiddlers into a hierarchy, and > then present the hierarchy as a menu. This is typically done by using > a plugin, and by tagging each child tiddler with the name of its > parent tiddler. This leads to two problems. One, this setup can be > accidentally broken when a parent tiddler is renamed. Two, this gets > in the way of using tags for just regular descriptive tagging. By > adding a "parent" field to each tiddler, this type of organization > could be supported natively. Those users who don't need it could > simply leave the parent field blank. The ability to add custom tiddler fields (as discussed above), means that anyone is free to add a plugin that creates and manages a 'parent' field for all tiddlers in their document. There is, of course, much more than simply *having* a parent field. For example, what happens if a parent tiddler is deleted? Does the 'grandparent' tiddler become the new parent, or is the tiddler 'orphaned'? If so, do you clear the reference to the parent, or leave it untouched in case the parent tiddler is re-created? Also, while one-to-one parent-child connections are perhaps the most common, what about multi-connected *graphs* rather than simple tree- like hierarchy? All sorts of one-to-many and many-to-many *semantic connections* are meaningful, such as "groupings" (where a tiddler can be in multiple groups), "inheritance" (where properties/values from other tiddlers are applied automatically), etc. The structure and handling rules that you need depends entirely upon the specific use-case, so it's not really practical to build one particular implementation directly into the TWCore, since it is likely that people will still need to override whatever core-default structure/handling is provided in order to meet their own needs. your thoughts? -e Eric Shulman TiddlyTools / ELS Design Studios -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
