Posting from the answers Jeremy gave me in the usergroup thread [1]. > Parenthetically, and I should have replied to the original thread, > I've come to believe that aggregated tiddlers can be restrictive.
They add some restriction to the code.. but also a lot of flexiblity to the user. Are we a database or a wiki? And can't we be both? > In many cases the best way around seems to be to use synthetic > names (much as a database assigns numerical ids for records in > some situations). True, but think of a regular document, you would never do that to your page titles. Especially considering that titles are more than just titles for a tiddler, they are also headings and it identifies them in the mind of the user. > It sounds like some of the complexity you've got comes from the > nesting of tiddlers inside other tiddlers, and the need to re-invent > how to encode the metadata. I've found that pulling back to a simpler, > non-hierarchical model avoids this problem. If indeed there was _never_ any other way that a macro wants to process the tiddler text apart from (a) slices and (b) sections, this would be a conceptual departure from the current model. Slices are one sublevel of a tiddler and sections are also one sublevel of a tiddler. You can't have slices-per-section. Having slices per record per tiddler (or slices per section per tiddler) indeed adds a layer to everything involving this functionality. But the complexity regarding the supporting code lies not in the extra layer. All plugins that add formatters in order to look for patterns in the wikitext in order to add new syntax, will in fact need to be rewritten for EVERY text format you support. Other plugin examples closer to my topic would be plugins that list all of the outgoing links in the documents, or all images in tiddlers tagged "photoshop". It's the multi-format-support that adds difficulty in this case. The complexity then lies in recognizing the special tag I include in my tiddlers that define my records. You call it metadata. It is an addition to the four types of metadata called tags, fields, slices and sections. In the case of slices and fields, will there be separate code for each text-format? This is most likely. If so, it would not be hard for my record-plugin to write custom code too for all the supported formats. This could be a plugin that really lays a foundation for other plugins to build on. Record-aware Listing macro's would call getRecord before calling getSlice on it. Others would simply call getSlice directly. The display of tiddlers does become more complex. There would be two modes: 1) direct rendering of the tiddler using a view-template that calls several macros to deal with tags, fields and text. 2) rendering of the tiddler using an standard view-template that calls an iteration macro that utilizes a special view-template to render the records and wikifies the remaining content These two paths would not always produce identical results for single- record tiddlers. A data application would likely choose one of the two approaches, not both. I agree that this is not a very beautiful approach. It is said that the greatest complexity is the greatest simplicity but in this case the complexity is rather ugly. It is not something to include in the core. Except for the required method Tiddler.prototype.getSlice(). That is beautiful. I would still personally take this approach for my project because the added ugliness for the code is balanced by the added beauty for the user imo. What you get is this: _a platform for data applications that is layered on top of page-formatted tiddlers_. This would not be something exclusive to TiddlyWiki, in principle. But tiddlers are more suited for this then normal pages, because tiddlers are small, they exist in memory, they will never contain more than say 20 records depending on view-format, and they already have slicing mechanisms in place which would be a format completely alien to other wikis. It also somewhat bridges the gap between all-data-in-a-table and every-row-in- a-tiddler. But the plugin would have to account for all of the possible text- format-plugins and provide regexp patterns for all of them. This is no different from other plugins that add syntax though! One could argue that if I wanted to include tiddlers in tiddlers, I should use TagglyTagging. But that doesn't take away from the difficulty of naming them and also doesn't provide a page-like collection of records. On the other hand, I could hand-create a custom index page that includes tiddlers with custom view-templates and view- editing-controls for all fields, but this cannot work for slices (readonly), only for fields. I would need to create unique names for all the tiddlers but I would manage and view them on the index-page. The index pages would simply call <<tiddler>> macros on the individual records. Then I need not deal with the individual tiddlers anymore. I can even excludeList them. I could even create them and give them a synthetic name from the management interface at the top/bottom of the tag-page. But all of this would be a solution - although very simple in its design - a lot less powerful. And, not less importantly, it would never be a foundation for building other multi-record-aware applications, except that it will be a final solution in itself. Reorganizing those index-pages would not be any different than copying links around, except that the "<<tiddler>>" calls would reference non- discriminate tiddler-names to other tag-pages so it becomes somewhat messy. I bet this is how most tiddlywiki databse adaptations do it. Just don't let the user see the tiddlers in the first place. Provide an interface for management and creation and display. Don't use slices, use fields. Agh but it SO takes away from the tiddler-is-a-page concept. I understand that true tailormade specialized sophisticated special- purpose applications do it in this way. Just records. No pages. No free flow text. No organic organizing. I believe multi-record tiddlers would be more powerful in providing applications that are not entirely specialized but which combine page- like editing and display with added data automation abilities. The data automation would be a layer "above" the page-editing, not replacing it. It would be the symbiosis between wiki-text editing and automated applications. Let me know what you think. ~Xen [1] http://groups.google.com/group/tiddlywiki/browse_thread/thread/33f9cb46d5d15566 -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" 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/tiddlywikidev?hl=en.
