Hi Tobias,

>>    1. Tabs fields: fields like *filter* and *template* have changed to 
>>    *list.filter* and *list.template*, and other fields have been added.
>>
>> Perhaps use a more specific *mt* prefix, e.g. *mt.filter*?
>

Yes, you're right. Maybe *mt.list.filter*, *mt.list.filter.heading*, 
*mt.list.filter.template, 
mt.tab.template*, etc.


 

> Its very easy: if you create a tiddler tagged $:/tabs/foo, it will appear 
>> as a bottom tab in every tiddler tagged $:/type/foo and only there (unless 
>> you choose to have it as a default tab, and you can do that with the tag 
>> $:/action/is/default, or go to the control panel, under appearance and 
>> magic tabs tweaks). 
>>
>  
>
> I explain how to create custom new types and tabs in 5 easy tabs here: 
>> http://youtabs.tiddlyspot.com/ 
>> <http://www.google.com/url?q=http%3A%2F%2Fyoutabs.tiddlyspot.com%2F&sa=D&sntz=1&usg=AFQjCNE0MHdJdh229zGaOMMkBuzvz0JgZA>
>
>
> Not sure what to make of this strategy in terms of...
>
> *Type video: *Add the tag $:/type/video to the video tiddlers. In this 
>> case: Introduction To TiddlyWiki
>> *Type annotation: *Add the tag $:/type/annotation to the annotation 
>> tiddlers.
>
>
> Why would I need an additional type tag? Isn't there a filter expression 
> that corresponds to what makes a tiddler of type *$:/type/video* or 
> *$:/type/annotation* or any other type?
>

Why an additional type tag ($:/type/annotation) ? It is not mandatory, but:

   1. that way it is easier to look for video annotations and create list 
   filters. You do the same using fields.
   2. if you fill the field *contents.tag* with that tag, the macro 
   <<tabContents>> will automatically display a list with a default filter 
   using that tab. But you can use your own list filter, either using the 
   field *list.filter*, or not using the <<tabContents>>.
   3. if you create the tiddler $:/type/annotation with a caption, an icon, 
   a template, they are automatically used by the macros <<tabCaption>> and 
   <<inputSlider>>.
   4. last but not least: *that way, annotation tiddlers can be first class 
   citizens*, having their own dedicated tabs, view templates, etc. For 
   instance, you may want a tab specific to video annotations showing related 
   with the same topic, or documentation tiddlers talking about the same topic 
   as the video annotation. 



> How about something more implicit, like...
>
> *$:/type/**field/**yt-id*
>
> ...without a need to declare some otherwise unneeded extra tags for 
> magic-tabs? 
>

> And then have ...
>
> *contents.by.field: $:/type/field/yt-video*
>
> ...perhaps. The thing is, do I need / also want those *$:/type/video* and 
> *$:/type/annotation 
> *tags now and does that mean that I also need to overwrite the tags 
> template?
>

Sorry, I don't understand your point.


 

> I was surely considering of abandoning the yt-video field as it seems much 
> more natural to have the annotation simply tag to the video, but then I 
> have the problem that a simple tagging relationship isn't a qualified one.
>

You need a qualified relationship between the video and its annotations, 
and the *yt-video* field works. You could use in the same way I use the 
*source* field. But if you use yt-video instead of source, you need to 
create specific list filters while source is used by default in MagicTabs.
 

>
> Also, if I kept something like *yt-video* as a qualified field then there 
> is that problem with generally distinguishing *yt-video* vs. *yt-videos*... 
> because, the latter would require a bracketed list like the tags field and 
> all the handling that  goes with dissecting those bracketed list-items 
> whereas the *yt-video* field as a reference to a single *parent* does not 
> have any double square brackets and would probably fail if I wrapped those 
> tiddler titles in them.
>

Custom list fields are a pain in the neck. But I managed to have them 
working with fields like *authors*, *about*, *parent*, and I don't remember 
if *source*.
 

> So, how do you harmonize these relations ships such that 1:1 is working 
> exactly like a 1:many in terms of how the data is being kept, i.e. by 
> entering that related tiddler via a "browse for some tiddler" popup just 
> like we have for tags?
>

> Mhhh, loads of further exploring and architectural design is needed, it 
> appears.
>
> I mean, hw would you handle the case where a tiddler would have two 
> parents, sources, etc...?
>

Its complicated but it works. When I have more than one author for the same 
book, they are all specified in the *authors* field and are treated as if 
they were tags. Idem for the *about* and *parent* field. Can't explain 
here. 

 Best wishes,

Alberto

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

Reply via email to