How to copy contents of system Storylist tiddler to another tiddler and back again?

[jonnie45]

Hi,

I want to play around with the following steps

1. Copy the list field of the Storylist tiddler to a similarly named field in an ordinary, otherwise virgin ‘storage’ tiddler.

2. Do the reverse operation, copy the stored version of the Storyriver in the list field of the ‘storage’ tiddler back into the list of the Storylist tiddler clearing any existing content first.

I want to play around with storing story river workspaces, I am aware of other views about how to go about this and projects in progress in this area but I would like to explore this way of doing things - for other views and ideas (replies from others to my first post on this subject) see Save Current Story River As A Workspace - #17 by jonnie45

I have found and played around with the following code from Saqimtiaz in response to a question about cloning a tiddler.

Cloning a tiddler

Hi, i am trying to put a clone button inside a tiddler , all i really want is to have a clone tiddler button similar to the one in the menu i can put a button widget along with a tm-new-tiddler command, but then would have to state every single field i want copied , but i have many fields ,and some fields might be added later . so is there like some parameter or command that encompasses the entire tiddler including all fields so ,that if combined with tm-new-tiddler , tiddly wiki would un…

<$button message="tm-new-tiddler" param=<<currentTiddler>> >
clone
<$button>

But I am having difficulty working out how to change this when I want the param to be something other than the currentTiddler - the above code seems to be suited at a button on a tiddler we intend to clone.
I want to achieve something similar to the above code but copying from the Storylist tiddler. Of course this does not solve my problem of how to copy the stored field back to the Storylist so I am hoping for a solution that can work both ways. At this stage I am just playing around trying to find a mechanism to get this working.

Thanks!

[TW_Tones]

The first part in the save and restore of the story;

This is a quick demo of one approach;

<$button setTitle="$:/SavedStoryList" setField=list setTo={{$:/StoryList!!list}}>
Save
</$button>
<$button setTitle="$:/StoryList" setField=list setTo={{$:/SavedStoryList!!list}}>
Restore
</$button>

• The above uses the simplest method
• If you want to add other action use the button actions parameter=actions-macro>> which contains your actions, you can also use the actionsetfield widget

I have other solutions for creating tiddler with multiple fields. But how far does this take you? I am off to bed.

[jonnie45]

Thanks TW_Tones, I will try it out - sleep well

[jonnie45]

Following on from TW_Tones’ helpful answers Here is my very crude first attempt, intended use is that the code goes into a tiddler with tag $:/tags/SideBar so that it is available as a sidebar tab - well that’s the way I have prototyped it.

I already have a tag called ‘z hidden’ which I use to hide tiddlers that I do not usually wish to see on the Storyriver but which I don’t want to bury as extra ‘system’ tiddlers - my various customisations over time all use this system.

The current situation is that the saved workspace/Storyriver will be saved in a tiddler called ‘UnNamed Workspace’ and this will be over-written by subsequent saves unless the tiddler is renamed to something meaningful like

“Workspace - where I got to 10pm last night”

or perhaps

“Workspace - 6Nov2023 - need to collate and interlink these tiddlers”.

The second part of the code - the restore workspace part - then lists all tiddlers with tag “workspace” and supplies alongside a button to restore that particular workspace to the Storyriver.

<$button setTitle="UnNamed Workspace" setField=list setTo={{$:/StoryList!!list}}>
<$fieldmangler tiddler='UnNamed Workspace'>
<$action-sendmessage $message='tm-add-tag' $param='z hidden'/>
<$action-sendmessage $message='tm-add-tag' $param='workspace'/>
</$fieldmangler>
Save
</$button>



<br>
<br>

<$list filter="[tag[workspace]sort[title]]">
<$button setTitle="$:/StoryList" setField=list setTo={{!!list}}>
Restore
</$button>
<<currentTiddler>>
<br>
</$list>

There was a discussion elsewhere on how to structure this, for me this simple approach at this stage seems to be just what I wanted (time will tell) the workspace tiddlers can be accessed directly and hacked manually (tiddler edit or delete) if I want a quick change I have not coded for, if I want to manually add or remove a tiddler from a workspace I can edit the list directly in the tiddler etc, lots of ways of achieving a particular result.

I guess I will tweak and refine over time but these few lines of code pretty much do at least 90% of what I wanted.

Planned improvements

• Add a delete button for each workspace.

• Refine process of re-naming a workspace tiddler from the default of ‘UnNamed Workspace’

The thing I like about the simplicity and use of tiddlers to carry the data here is that I can start working straight away and manually hack any of the functionality on the list above. Transparent and accessible.

Thanks for the help TW_Tones, I just needed that first bit to get it rolling.

[EricShulman]

Hi @jonnie45,

Nicely done!

Just to get things moving a bit further, here’s an enhanced version of your code that adds a few features and demonstrates some nice wikitext coding techniques:

\define temp() $:/temp/saveworkspace
\define default() UnNamed Workspace

<$edit-text tiddler=<<temp>> tag="input" default=<<default>>/>
<$let name={{{ [<temp>get[text]else<default>] }}}>
<$button tooltip="save current workspace">{{$:/core/images/save-button}}
<$action-confirm $message={{{ [[Are you sure you want to replace ]addsuffix<name>] }}}
   $prompt={{{ [<name>is[missing]then[no]] }}}>
   <$action-setfield $tiddler=<<name>> text={{$:/StoryList!!list}} tags="[[z hidden]] workspace"/>
   <$action-deletetiddler $tiddler=<<temp>>/>
</$action-confirm>
</$button>
</$let>

<p/>

<$list filter="[tag[workspace]!has[draft.of]sort[title]]">
<$button setTitle="$:/StoryList" setField=list setTo={{!!text}} tooltip="use this workspace">
   {{$:/core/images/done-button}}
</$button>
<$button message="tm-edit-tiddler" tooltip="edit this workspace">
   {{$:/core/images/edit-button}}
</$button>
<$button tooltip="delete this workspace">
   {{$:/core/images/delete-button}}
   <$action-confirm $message={{{ [[Are you sure you want to delete ]addsuffix<currentTiddler>] }}}>
      <$action-deletetiddler $tiddler=<<currentTiddler>>/>
   </$action-confirm>
</$button>
<$link/>
<br>
</$list>

Notes:

• For convenience, we define a few useful text values as macros (temp and default) at the top of the tiddler. This allows these values to be referenced in several places without having to repeat the text each time.
• Then, we start with an $edit-text widget for entering a name for the workspace to save. This input is stored in the <<temp>> tiddler. The $let that follows it gets this input as a variable. If the input was blank (or unchanged from the default), then we use the <<default>> value.
• Next, we show a “save” button (using the $:/core/images/save-button icon). This button uses $action-confirm to ask for confirmation before saving the workspace. If the new workspace name does not exist, then we skip the message and just perform the actions.
  • The $action-setfield saves the new workspace, copying the $:/StoryList!!list field to the text field of the saved workspace and setting the desired tags on the saved workspace. By using the text field to store the list, it makes it easy to view the saved list contents just by opening the workspace tiddler.
  • We also delete the temporary tiddler so that the $edit-text input value reverts to the default for the next time.
• Following the “save” input and button, we list all the saved workspaces with a few buttons. Note that we exclude any saved workspaces that are draft tiddlers (i.e., saved workspaces that are currently being edited) from the list. For each workspace we show three buttons:
  • The first $button copies the saved workspace text field to the $:/StoryList!!list field.
  • The second $button starts a tiddler editor for the saved workspace
  • The third $button deletes the saved workspace. Note how $action-confirm is used to confirm before deletion.
• Rather than using <<currentTiddler>> to show the workspace name, we use <$link/>. This displays the workspace name as a clickable link, so that you can quickly view this workspace tiddler.

enjoy,
-e

[CodaCoder]

@jonnie45

Sadly, what follows is entrenched in my environment – it’s not usable standalone. But this screenshot might give you some UI/UX ideas:

[TW_Tones]

I mentioned elsewhere my desire to provide tools for easy list or set management with the story list just being a specific case. Idealy built into the current user interface in a minimalist way. Of course filters are a way to define dynamic lists and we need to find a way to deal with specific vs filtered lists or sets.

[jonnie45]

Many thanks Eric I am working my way through these improvements now, great enhancements not only functionally but visually as well - it’s also a good learning exercise. I am an infrequent TW coder but tend to find that the first port of call is usually to refresh by looking for similar examples in the customisations and plugins I have already written - having more professionally coded examples like yours in my existing set-up tends gives a basis which helps lead to writing better code later on etc… Great stuff! Thanks!

PS: Your use of the text field rather than the list field provokes interesting thoughts…

• I could follow your example, as you say promoting the story list tiddlers into the text field that is displayed and easily edited brings improvements. I think this would be the the way to go if there are no other reasons otherwise…

OR

• I could reserve the text field for comments about why I stored that workspace in the first place for instance “Remember to integrate contents of tiddler A into B and then delete tiddler A", also remember to improve on the title of tiddler C - current name sucks!”

The workspace description text mentioned in the latter of the above points could then appear in the toolbar below all of the buttons and be changed each time a different workspace is restored, maybe possibilities on this topic with tooltips as well - interesting lots to play with here!

Maybe I will try both ideas and see which one seems most useful.