Thank you both.
I've taken a look at Shulman's solution, his BookmarkList (simple
enough) and his BookmarkViewTemplate. I don't really like the idea of
loading the page referenced into an iframe when the tiddler containing
the bookmark is opened. I'd rather just see the tiddler contents and
my own data. I mean, imo one of the drawbacks of TW is that everything
happens within a single page. You cannot right-click and "open as
tab". Opening a link you'd want to browse *inside* the TW page seems
like a bad idea when you can open it in a new tab at the press of a
button. Nevertheless, the idea of having custom ViewTemplates for
tagged content is something to keep in mind.
The drawback is of course that you need to rewrite BookmarkList
manually if you want to change the 'document type definition'. That
seems not to be so big a problem for me at this point. Perhaps I don't
even need a template then. But I wonder how one would create an
adaptive system based on a html template + macros.
What we really need (as a community) is a database system that can be
implemented by an end-user without having to code any javascript.
Ideally, the default installation of TiddlyWiki should have several
general purpose applications that enhance the basic wiki functionality
with flashy javascript forms backed by tiddlers that are still easy to
read and edit. It shouldn't be necessary to create a new TW file for
each new application. Why should your address book be in
addressbook.html and your bookmarklist be in bookmarks.html? To me, my
main TW wiki is all about me as a person. It has several applications,
such as address book and bookmarks. I might create a 2nd wiki for my
spiritual knowledge base, and a 3rd wiki for everything to do with
programming. But applications are not limited to a single wiki, I
might use the same application in multiple wikis for distinct sets of
data.
I notice that my personal "bookmark" structure might not be as
universal as I (tacitly) assumed it was. Not everone needs "topic",
"category" or "summary". "description" would be more universal. My
bookmarks are all about articles. I should call them "article
bookmarks", "article stubs" or "article nodes". Their purpose is to
enclose the article itself within a metadata wrapper that provides for
me a research history, research summary, and point of personal access.
They are really stubs. How to tag them then?
But what I would like to do is to make the resulting package so easy
to modify that you could even have two separate systems of bookmarks
(one for regular bookmarks and one for article bookmarks) that share a
common tag ("bookmark") and actually display and/or manage them using
the same interface, as long as they have some primary fields in
common. "article bookmark" would in that respect be a subclass of
"bookmark".
The idea of hiding your fields is not a bad one if you are planning to
create a custom ViewTemplate for every type of database record you
create. (That is what /% .... %/ does right, hiding? But it doesn't
hide all things?). Perhaps you could even have a default ViewTemplate
for all "record" type tiddlers that simply displays the fields in a
nice format. But I'm not sure you can override that with another
ViewTemplate. Shulman's TaggedTemplateTweak matches tagViewTemplate in
the order of the tags. If you would add a "record" tag as the last tag
in the list, recordViewTemplate would get overridden by
bookmarkViewTemplate. It would require you to add another "record" tag
for every database application in addition to "bookmark". If tags
could be subclassed then a "bookmark" would simply be a "record" and
TaggedTemplateTweak could ascend the tag hierarchy to look for
matches. But that would interfere greatly with TagglyTagging and its
"tag everything, and then some more". Besides, tags do not always
denote an hierarchical or "instanceof" relationship. Without
subclassing, my article stubs would be tagged as "article bookmark
record". It does be a bit much. What it does provide us with is very
generic templates for displaying and managing any type of record! If
we can read out the names of the attributes as well as the 'slice
value' then we can just build a general purpose database template, but
it would use an aggregate of all the various types of records in the
wiki, hence not be very useful....
One question: is putting multiple records into the same tiddler a Bad
Thing? I think the whole slicing functionality would only work at the
first entry. If you want a view template based on slice values, the
tiddler also needs to be a single record. If you want to add
_unformatted_ content to a tiddler (below the hidden data section), it
also becomes messy if you have multiple records. But it shouldn't be
too hard to parse several records in the same tiddler. Actually, Mark,
you are also hiding the description even though it is not a field; how
do you retrieve this data if it's not a slice? Do you use it in your
ViewTemplate?
Okay so my questions
1) (a) use several record types that are subsets of each other
("article bookmark" and "bookmark") or (b) keep all record types
separate ("article" vs "bookmark")?
2) suppose we choose the former, any way of introducing "supertags and
subtags" (ie. inheritence) into our evil data scheme? (in principle
the tag "bookmark" or "record" or "article" denotes a table/data/
record class. The classes are not defined anywhere, but there is a
silent contract between the tiddlers and the template/listing script.)
3) do we (a) by default hide the "field: value" pairs inside /% ... %/
pairs and count on a default recordViewTemplate to show them again
(difficult? requires iteration), or (b) do we simply show them,
enclose them in a css wrapper {{record{}}} and leave it to the
bookmarkViewTemplate to hide them (.record { display: none; })
4) single-record tiddlers (unique names for every record) or multiple-
record-tiddlers (bookmarks for the same website or the same topic can
share the same name).
I think the record-subset idea doesn't require any special coding but
I doubt it is very useful (you are keeping two distinct collections,
no reason to show them together). Generic management for record
tiddlers would be limited to listing them with their other tags, and
deleting them. Each record type could have its own ListTemplate
though... it would be easy to list generic records with their non-
generic fields based on bookmarkListTemplate and articleListTemplate
and so on. Hmmmm :).
I think tag subclassing is out of the question.
I'm not sure many people would like the idea of having to tag their
records with both "bookmark" and "record".
If there is no "record" tag and also no default recordViewTemplate
then hiding all the data fields would require every application to
implement a taggedViewTemplate in order to show the data of the
tiddlers.
I think the present code library favors using single-record tiddlers
especially given the wikify slice syntax "here::Description" but
wikify is a plugin, but I would hate to lose the easy of just lumping
multiple records together in a single tiddler - after all, free form
editing is what a wiki is all about. But it would make view template
coding much more complex. I'm just going to name my tiddlers
CulturalRelativism1, CulturalRelativism2, etc. if I can't lump them
together.
@Anthony
Thanks for the links. I will check them out tomorrow.DataTiddlerPlugin
sounds like a promising building block.
--
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.
