Hey guys,
I would like to ask a question about something. It's not something I
am already considering to implement or build, but it'd like to know
what is possible; what the context is.
I have this idea about multi-record tiddlers. I know the slicing
mechanism treats the tiddler as a record so there is a 1:1 mapping.
But there is a drawback to this. First, you have to give every record
in your database a unique name. For certain data types (applications)
that can be quite annoying. Second, a record is something very stale,
much unlike a normal wiki page that can have text, markup, headings
and so on. From an end-user perspective, being able to put multiple
records into a single tiddler and add some descriptive free-form text
to it, or even a discussion or whatever, can be a very nice thing.
One example, suppose I create a database of small notes about articles
I've read. These notes are like bookmarks, they are stubs, points of
access to these articles for my own recollection. Now I might read an
article on cultural relativism and I might add it to a tiddler called
just that way "CulturalRelativism". Then I read another article about
it. It's not like I'm doing a complete study of everything on the
subject, so I add it to the same tiddler. I write my summary (part of
the record) and add some thoughts (free-flow text). Maybe I add some
text that describes both articles something I cannot do in a single
record. As I add more and more bookmarks on this subject, it might get
too much, so I split it into two or three tiddlers with more
descriptive titles. I dunno. It's all organic. I'm organically
organizing my data. I don't plan ahead, I just reorganize when I like
to.
But because we have a data application framework that can collect
records from tiddlers in whatever way they are distributed, I can
still harness some automation power. I can list all of the tiddlers I
have in my system (with a certain tag) and all of the records
contained in them (that don't have independant tags, after all, they
are under the same topic and title). I can do everything a standard
tiddly data application could do, except for deleting records from the
"management interface". The records are contained in free-flow text it
doesn't make sense to delete them individually.
The records would have to be identified by some wrapper such as
{{record{ ... }}} which would also immediately style the slice-table
or hide it from default view, depending on the implementation.
TaggedTemplateTweak would be used to render each of the record
sections individually and combine it with the rendering of the
surrounding wikitext, presenting a page-like tiddler.
So basically the argument is: wiki's are organic; imposing strict
rules on "data tiddlers" by turning them into records is
counterintuitive. A wiki can be a database, yes. But a wiki must
remain a wiki. The foundation is organic organisation and
reorganisation of text data that can contain structured data as well.
I'm not saying all applications would adhere to this standard, but
there are some that would. For a pure database it makes no sense. But
for a personal collection of artifacts it makes a lot of sense, to me.
----------
Now the details. As I understand it the slicing mechanism operates out
of the TiddlyWiki (store) object, and not out of Tiddler itself. The
supposed reason for this is that shadow tiddlers are not special
Tiddler objects but simple hashmaps to text, and for all of the
slicing functionality to work uniformly across these two incompatible
types of objects, it would have to operate out of the wrapper that
contains them. Seems like a bad design choice to begin with, after
all, why /not/ make a cool object out of them? There are not and never
will be that many shadow tiddlers to begin with, so it would make the
design more elegant without sacrificing performance. But, of course, I
can't argue with you on that score.
The problem is that for a slicing mechanism to work on records, I must
be able to extract the records from the tiddler and call .getSlice()
on them. The records I extract can either be real Record objects or
just nameless Tiddlers. If Tiddler has Tiddler.getSlice(), then I can
just call a new method Tiddler.getRecords() and iterate the nameless
Tiddlers that are returned to me. (These Tiddlers would simply contain
the {{record{ ... }}} section of text).
It would add a new layer of functionality to the tiddler structure but
it would be completely transparent, that is to say, nothing would
change, and only the multi-record aware code would even know of the
getRecords() method. The normal single-record getSlice() and the multi-
record getRecords()[i].getSlice() would coexist peacefully.
The tiddler::key format would still only reference single-record
slices. Only data macros and scripts would know how to traverse these
records and how to display them. Default ViewTemplates would simply
display the tables (provided they haven't been hidden in CSS) and
application-specific ViewTemplates would know how to render them. The
{{record{...}}} wrapper could also be made flexible by allowing the
getRecords() method to receive a parameter "datatype" that's based on
the predefined tag for the application and is thus known by the data-
plugins responsible for traversal and display. A tiddler tagged as
"bookmark" would define its records by {{bookmark{ ... }}}. This
provides for flexible default styling and hiding of the table, whereas
application-specific plugins would provide viewtemplates and
edittemplates. The macro code would mostly be generic for the data
application framework (and I'm sure that that's how it's already being
done).
So, to wrap it up....
1. Tiddler.getRecords()
2. Tiddler.getSlice()
3. the ability for getRecords() to create nameless tiddlers that are
not entered into the store.
and we're set to go ;-).
Let me know what you think. I'm probably missing something.
--
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.
