Implementing tag functionality in other fields

[c pa]

Tell me if I'm going about this the right way.

I want to implement the tags functionality (push and pop) on other fields because I'm pushing and popping non-semantic elements and I don't want them polluting my list of symantic tags.

Should I clone checkbox and hastag into myfieldcheckbox and hasmyfield and change the fieldname being manipulated from tiddler.fields.tags to tiddler.fields.myfield

or is there a better way?

[Matabele]

Hi

On Friday, August 29, 2014 8:16:00 PM UTC+2, c pa wrote:

I want to implement the tags functionality (push and pop) on other fields because I'm pushing and popping non-semantic elements and I don't want them polluting my list of semantic tags.

I have come across the same issue and was thinking along the lines of creating plugins to manipulate elements of all fields. After a brief discussion with Jeremy, I concluded that it was necessary only to have one other field that behaves like the 'tags' field for this purpose -- I considered calling this field 'systags'.

This behavior of the 'systags' field  would be a little easier to replicate than extending tag like behavior to all fields. Anyway, I believe efforts in this direction will be worthwhile i.e. clone the behavior of the 'tags' field for another 'systags' field -- systags could then be used for all non-semantic purposes.

regards

 

[Jeremy Ruston]

Assuming we're talking about TiddlyWiki5, I think it's a reasonable goal to be able to treat any other field like the tags field.

There's actually very few components of TW5 that specifically "know" about the tags field:

* tag filter: could be extended to identify the tag field to be used eg [tag:mytagsfield[exampletag]]

* tags filter: similarly [tags:mytagsfield[]]

* tagging filter: similarly [tagging:mytagsfield[]]

* untagged filter: similarly [untagged:mytagsfield[]]

* checkbox widget: could be extended with an additional attribute to identify the tag field to be used

* fieldmangler widget: similarly

The infrastructure in wiki.js concerned with caching the tag map would also need to be tweaked.

Best wishes

Jeremy

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[c pa]

>> On Saturday, August 30, 2014 12:40:32 AM UTC-7, Jeremy Ruston wrote:
>>Assuming we're talking about TiddlyWiki5, I think it's a reasonable goal to be able to treat any other field like the tags field.

Yes Tiddlywiki5

>>There's actually very few components of TW5 that specifically "know" about the tags field:

>> * checkbox widget: could be extended with an additional attribute to identify the tag field to be used

I extended hastag() so I could pass a fieldname
I started hacking $checkbox and it turns out that there is some mechanism that converts tiddler.fields.tags into an array so that tags.push() and tags.pop are valid actions

I'm guessing that there is a field handler that does that conversion. Could you point me to where that code resides?

[Jeremy Ruston]

Hi c pa

On Fri, Sep 5, 2014 at 1:47 AM, 'c pa' via TiddlyWiki <tiddl...@googlegroups.com> wrote:

I started hacking $checkbox and it turns out that there is some mechanism that converts tiddler.fields.tags into an array so that tags.push() and tags.pop are valid actions

I'm guessing that there is a field handler that does that conversion. Could you point me to where that code resides?

The field handler that deserialises the `tags` field into an array is here:

https://github.com/Jermolene/TiddlyWiki5/blob/master/boot%2Fboot.js#L809

If you want to treat another field as an array (one that hasn't been automatically deserialised), you need to do is something like this:

var myTiddler = wiki.getTiddler(title);

var myFakeTags = $tw.utils.parseStringArray(myTiddler.fields["my-fake-tag-field"]);

myFakeTags.push("anotherTag");

wiki.saveTiddler(new $tw.Tiddler(myTiddler,{"my-fake-tag-field": $tw.utils.stringifyList(myFakeTags)));

Best wishes

Jeremy

 

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[c pa]

OK I've made the code changes and tested them for

* tag filter: has been extended to identify the tag field to be used eg [tag:mytagsfield[exampletag]]

* tags filter: similarly [tags:mytagsfield[]]

* untagged filter: similarly [untagged:mytagsfield[]]

* checkbox widget: has been extended with an additional attribute to identify the tag field to be used

So I've got the abiilty to execute lists and dashboards without clogging up the tags with non-semantic content

The tagging filter would be nice to implement "relatedness" between tiddlers and use different field names to signify the semantic meaning of that relationship
>> * tagging filter: [tagging:mytagsfield[]]
I can't figure out how I would pass operator.suffix into $tw.utils.pushTop(results,options.wiki.getTiddlersWithTag(title));

Tagging.js calls the following functions:
this.getGlobalCache("taglist-" + tag,function() {
var tagmap = self.getTagMap();
this.getGlobalCache("tagmap",function() { });

The fieldmangler widget would be nice to implement button controls

>> * fieldmangler widget: similarly

Could you give me a clue on how I should approach this one?

[Jeremy Ruston]

Hi c pa

> I can't figure out how I would pass operator.suffix into $tw.utils.pushTop(results,options.wiki.getTiddlersWithTag(title));

A new parameter needs to be added to getTiddlersWithTag() to indicate which tag field is to be used. The cache handling will also need to be changed to take into account the name of the tag field being used.

>> * fieldmangler widget: similarly

>Could you give me a clue on how I should approach this one?

This is more difficult. The tm-add-tag message only accepts a single parameter (the tag name), and there's currently no facility for adding additional parameters.

I suspect that the best approach for the moment would be to add an attribute to the fieldmangler widget to indicate which tag field should be used.

Best wishes

Jeremy.

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[William Jackson]

Hi

I have written a <$mangletags> widget (yet to be updated to 5.0.16) which may be more suitable for modification than the <$fieldmangler> widget -- have a look here: http://gwiz.tiddlyspot.com/

regards

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/YCqfv30JQNs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

[c pa]

Ah hah. Thanks for this. I put what I've done at http://cpashow.tiddlyspot.com/

[William Jackson]

Hi

Thanks -- this addresses a problem I had. You may also be interested in the <$makelist> widget -- this will fill a specified field with the output of a filter expression.

regards

On Tue, Sep 9, 2014 at 6:38 AM, 'c pa' via TiddlyWiki <tiddl...@googlegroups.com> wrote:

Ah hah. Thanks for this. I put what I've done at http://cpashow.tiddlyspot.com/

--

[c pa]

I've fixed several defects and posted them to http://cpashow.tiddlyspot.com/

Is there a method to put in the following fix without directly editing the boot.js code?

To fix them I had to directly edit boot.js to add the following for each field I wanted to use:

$tw.modules.define("$:/boot/tiddlerfields/[fieldname]","tiddlerfield",{
    name: "[fieldname]",
    parse: $tw.utils.parseStringArray,
    stringify: $tw.utils.stringifyList
});

[Matabele]

Hi

My <$makelist> plugin explicitly saves the list in space separated form -- this avoids the necessity of preformatting fields (as is the case for the 'tags' field.) It may be possible to similarly modify the various widget plugins thus avoiding the necessity of editing boot.js.

regards

[Jeremy Ruston]

Hi c pa

 

Is there a method to put in the following fix without directly editing the boot.js code?

To fix them I had to directly edit boot.js to add the following for each field I wanted to use:

$tw.modules.define("$:/boot/tiddlerfields/[fieldname]","tiddlerfield",{
    name: "[fieldname]",
    parse: $tw.utils.parseStringArray,
    stringify: $tw.utils.stringifyList
 }

You can create a JS module with the module-type "tiddlerfield" that exposes the same properties; the core will load it as part of the boot process.

But adding a tiddlerfield module is not recommended. It means that all code that attempts to read that field will return an array, rather than a string.

The recommended approach is to use $tw.utils.parseStringArray when you read your field to convert it into an array, and then use $tw.utils.stringifyList when you write your field to ensure that it gets written as a string.

Does that make sense?

Best wishes

Jeremy

 

);

--

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+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[c pa]

>> You can create a JS module with the module-type "tiddlerfield" that exposes the same properties; the core will load it as part of the boot process.

Yay! That worked and I got all the other pieces to work too. I've posted the results at http://cpashow.tiddlyspot.com/

>> But adding a tiddlerfield module is not recommended. It means that all code that attempts to read that field will return an array, rather than a string.
>>The recommended approach is to use $tw.utils.parseStringArray when you read your field to convert it into an array, and then use $tw.utils.stringifyList when you write your field to ensure that it gets written as a string.
>>Does that make sense?

Yes that does make sense. Because some people will want to implement the functionality as space separated lists while other will want to implement it as arrays (Which is how I want to do it, but I understand the need)
OK, so more work tomorrow. I'll add some code that checks to see if the field is an array or not before doing the assignments.
I'll post here when I get it working.

[Jeremy Ruston]

Hi c pa

>> You can create a JS module with the module-type "tiddlerfield" that exposes the same properties; the core will load it as part of the boot process.

>Yay! That worked and I got all the other pieces to work too. I've posted the results at http://cpashow.tiddlyspot.com/

I'd recommend against the approach of adding a tiddlerfield module (and I regret using them in the core). If you then have components that rely on the field being an array then those components won't work on other fields that haven't been treated with a tiddlerfield. This reduces flexibility for the user to apply those components to whatever fields they want.

OK, so more work tomorrow. I'll add some code that checks to see if the field is an array or not before doing the assignments.
I'll post here when I get it working.

You don't need to check whether the field is already an array; $tw.utils.parseStringArray will happily cope with strings or existing arrays.

Best wishes

Jeremy.

 

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[c pa]

>> I'd recommend against the approach of adding a tiddlerfield module

Okay. I've implemented the functionality so it works for both tagfields and text fields, so you can use it to manage lists of items using checkboxes and buttons on both
Posted at http://cpashow.tiddlyspot.com/

Not yet packaged - probably won't get to that till after the release.

I've also managed to make it work for the tag, tags, tagging, and untagged filters.

On the untagged filter I noticed that it also returns all tiddlers that don't have the field. So should I tweak untagged so it doesn't return a tiddler if it doesn't have the field? Or should I create a filter that searches for the presence of a field on the tiddler?

My next item is to implement the ability to control the reveal widget by searching for the presence of a tag on a tiddler. This looks like it should be easy but I'm having some trouble figuring out how to correctly call wiki.getTiddler

RevealWidget.prototype.execute = function() {
    // Get our parameters
    this.tagfield = this.getAttribute("tagfield");
};

RevealWidget.prototype.readMatchState = function(state) {
    if (this.tagfield) {
        var tiddler = this.wiki.getTiddler(this.stateTitle);          //not executing as expected
        this.isOpen = tiddler.hasTag(this.text,this.tagfield);
    } else {
        this.isOpen = state === this.text;
    }
};

[Jeremy Ruston]

Hi c pa

Is your code available on GitHub? It would easier for me to inspect it and provide comments there.

> My next item is to implement the ability to control the reveal widget by searching for the presence of a tag on a tiddler.

I originally thought that functionality would be necessary but it turns out that the list widget can already do it:

<$list filter="[is[current]tag[mytag]]" emptyMessage="Displayed if the tiddler doesn't have the specified tag">

Displayed if the tiddler does have the specified tag

</$list>

> This looks like it should be easy but I'm having some trouble figuring out how to correctly call wiki.getTiddler

I don't see anything wrong with the code you've provided.

Best wishes

Jeremy

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[c pa]

I deleted my previous post because the error is in my code not in TiddlyWiki.

[Joshua]

+1 to the idea of giving other fields functionality similar to "tags filter" and "tagging filter" as Jeremy mentions above. It would be great to see this functionality in the core or in a plugin soon. I have been trying to figure out how to create triple stores and then create nested lists based on the triples. If anybody has implemented such a thing into a plugin successfully and it slipped my notice (or without one), please post and let me know. Thanks.

Joshua

[Tobias Beer]

+1 ...add me to the list ...always found it very appealing to leverage independent tag buckets

Best wishes, Tobias.