An update:
I have tagging on import working for multiple files now also.
For the record, I replaces the split and removeprefix/suffix with some
splitregexp 's
\define tag-import-actions()
<$set name="preregfilter" value="# \[\[">
<$set name="sufregfilter" value="\]\]">
<$list
filter="[[$:/Import]get[text]splitregexp<preregfilter>splitregexp<sufregfilter>each[]]"
variable=imported>
<$fieldmangler tiddler=<<imported>>>
<$action-sendmessage $message="tm-add-tag" $param=<<currentTiddler>>/>
</$fieldmangler>
</$list>
</$set>
</$set>
\end
There is a lot of extra cruft that get generated by the splitregexp but the
each[] filters out everything that is not a valid tiddler title and should
keep things from being too brittle with $:/Import format changes.
I will get to drag and drop of external resources and maybe integrate in
canonical_URIs in the future but right now, this fits 99.99999% of my
needed use-case.
I am still wondering about proper use of the "tv-auto-open-on-import"
variable. What Tony wrote about "tv-enable-drag-and-drop" makes me think
there is a tiddler that I should be globally poking that value into rather
than it being a locally controlled thing.
/Mike
On Wednesday, June 17, 2020 at 12:49:31 PM UTC-3 Michael Wiktowy wrote:
> Hi Tony, et al.,
>
> I have come to similar conclusions. While JSON manipulation looks to be a
> powerful tool (once I figure out how to use it), but I have been continuing
> to try to make things work with vanilla TW and finally come up with a
> solution for the $browse macro at least. Having a list of imported tiddlers
> after import and having some dedicated post import action trigger would be
> incredibly useful. But I managed to fake it and force the right order of
> processing.
>
> I reused parts of the import template from within the tiddler and
> triggered the tm-perform-import from within the $button body (as you
> indicated) and then scrape the resulting list of imported tiddlers that
> pops up in $:/Import and add tags to the list in the "actions" parameter
> that is triggered after the actions in the body.
>
> To that end, cut and pasted the Import tempate into my local tiddler and
> added a button:
> <$button actions=<<tag-import-actions>>>Import and TagHere
> <$action-sendmessage $message="tm-perform-import" $param="$:/Import"/>
> </$button>
>
> where tag-import-actions is:
>
> \define tag-import-actions()
>
> <$set name="titleprefix" value="[[">
> <$set name="titlesuffix" value="]]">
> <$list filter="[[$:/Import]get[text]split[#
> ]removeprefix<titleprefix>removesuffix<titlesuffix>]" variable=imported>
> <$fieldmangler tiddler=<<imported>>>
> <$action-sendmessage $message="tm-add-tag" $param=<<currentTiddler>>/>
> </$fieldmangler>
> </$list>
> </$set>
> </$set>
> \end
>
> Lessons learned/remaining issues:
> 1) If I had two $list widgets in the actions, the second one would not
> process a field set by the first one. I initially tried to scrape the list
> directly into a Title List that I stuck into a field that I would later
> access with a list operator but second $list widget filter would fire
> first. Only having one $list widget with all the removeprefix/suffix mess
> worked.
> 2) removeprefix cares about leading spaces and split does not remove them
> unless told to :]
> 3) Whether to use a "$param" vs a "param" is annoyingly unclear ...
> $field=name sometimes means $<name of field>=<value to assign to field> and
> sometimes $field=<name of field> and some subsequent $value=<value to
> assign to field> and othertimes <name of field>=<value to assign to field>
> is sufficient. Not sure how many times I got caught up in that subtle
> syntax change. Maybe there is a hard and fast rule for when to use which
> syntax but I ended up with many head-slapping moments.
> 4) <$set name="tv-auto-open-on-import" value="no"> seems to get ignored by
> <$browse> to suppress the $:/Import tiddler from popping in to the Story
> list. Either I am misinterpretting what that is supposed to do,
> mis-applying it or there is a bug.
> 5) While the intent of the $list widget is to be able to process multiple
> files, there seems to be something wrong where it only processes and tags
> one of the imported tiddlers. {{{ [[$:/Import]get[text]split[# ]rest[1]]}}}
> seems to list both. Still scratching my head on that one so for the time
> being $browse does not have "multple" in it.
>
> I think using your $:/config/DragAndDrop/Enable might fix that easily but
> I think what I have is in a usable state at
> http://mwiktowy.tiddlyspot.com/#ImportHere
> <https://mwiktowy.tiddlyspot.com>
>
> Thanks for everyones help!
> /Mike
>
>
> On Wednesday, June 17, 2020 at 1:34:52 AM UTC-3, TW Tones wrote:
>>
>> Folks,
>>
>> I just revisited this thread with a clear mind,
>>
>> This is a technical musing which may provide some interesting options.
>>
>> I realised there are two kinds of manipulations we need to do on incoming
>> tiddlers. One is pre-import, acting on them before import, or at least
>> before unpacking the import JSON and those post import.
>>
>> - The first pre-import needs interrogation of the JSON file created
>> with the import process;
>> - The Second post import needs to act on the tiddlers imported.
>>
>> So we need json handling, eg Joshua's tools for the first, and with the
>> second we can use any tool for post import processing as long as we have
>> access to the list of imported tiddlers.
>>
>> It seems to me if we can enhance the import process to generate a list of
>> imported tiddlers, that can be used programaticaly, and use this list for
>> any post processing that will be handled.
>>
>> In the pre-processing step it seems we need to be able apply these
>> minimum functions
>>
>> 1. Import all tiddlers with a prefix or suffix added, so they do not
>> overwrite and existing tiddlers, or can be bundled for later processing.
>> 2. Be able to apply a filter to the incoming tiddlers and chose which
>> in the import list is to really be imported, perhaps even by comparison
>> to
>> existing tiddlers.
>>
>>
>> - However if the 1st step is available we can do the 2nd in a post
>> processing with a prefix awareness.
>>
>> In fact one way of doing the equivalent to item 1 above is to turn the
>> import tiddlers into a plugin (rename plugin-type to plugin) , then the
>> imported tiddlers become shadow tiddlers. But shadow tiddlers are never the
>> less tiddlers and may override and existing tiddler when accessing the
>> imported tiddler name.
>>
>> Another way is to save the import to ar JSON tiddler (Which it is) and
>> process that later.
>>
>> Regards
>> Tony
>>
>>
>> On Saturday, June 13, 2020 at 4:07:27 PM UTC+10, TW Tones wrote:
>>>
>>> Joshua
>>>
>>> Lovely work like usual. I knew the json mangler plugin would start to
>>> pay off with particular applications like this.
>>>
>>> I would be keen to apply filters and actions to the json tiddlers during
>>> import to add or remove title prefix/suffix or field value pairs.
>>>
>>> This would allow importing tiddlers that would overwrite existing ones
>>> under a different namespace and keeping them there or allowing a difference
>>> check and commit process. This could help with multiple contributors
>>> submissions such as via the comments plugin.
>>>
>>> I expect even just a subset of json mangler features to handle import
>>> and json files would go a long way.
>>>
>>> Thanks
>>> Tony
>>>
>>>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/fd392384-5004-4564-9292-ae9496da3f3fn%40googlegroups.com.
