TW5 new tiddler (tm-new-tiddler) create in view mode?

[Dave]

Hi, I searched for this and found a similar thread, but it was about TWC, so here goes:

I have this macro that makes a new tiddler based on a template tiddler when you click on an icon:


\define newRaceTags()
[[$(currentTiddler)$]]
\end

\define newRace()
<$button class=<<tv-config-toolbar-class>>>
<$action-sendmessage
  $message="tm-new-tiddler"
$param="race template"
title="$(currentTiddler)$ -"
  tags=<<newRaceTags>> />
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{swimmerIcon}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text="new race"/></span>
</$list>
</$button>
\end


How do I make it create it and open it in view mode instead of edit mode?

I tried searching for "tm-new-tiddler" at tiddlywiki.com, but didn't find anything that helped.

[Tobias Beer]

Hi Dave,

Not entirely sure, but I believe the option to have tm-new-tiddler actually create and save the tiddler instead of just opening the editor does not exist yet.

Best wishes,

— tb 

[Matabele]

Hi

I wrote the $maketid widget to address this problem some time ago - I have recently updated this widget in the form of an action widget.

The $x-maketid widget may be found here. 

The newly created tiddler may be opened in the background, or in view mode or in edit mode. There are a number of other enhancements which can't be done with tm-new-tiddler -- you may find these useful.

regards

[Tobias Beer]

Hi Matabele,

 

The $x-maketid widget may be found here. 

The newly created tiddler may be opened in the background, or in view mode or in edit mode. There are a number of other enhancements which can't be done with tm-new-tiddler -- you may find these useful.

Would the code-overhead be too much for a PR / did you already go down that road? It's just that I've seen this request pop up a few times now and I think it's perhaps core worthy to more silently create tiddlers that way.

Best wishes,

— tb

[Matabele]

Hi Tobias

Creating tiddlers in view mode or in the background seems to be an essential feature when writing applications -- I see a need for this in the core.

No -- the widget is fairly small but does duplicate some of the code in the $navigator widget. The $action-maketid widget should however, render the 'tm-new-tiddler' redundant (might need a few tweaks to correctly update $:/HistoryList and $:/StoryList) -- the listener in the $navigator widget could then be removed at some stage.

My reason for not submitting to the core: I don't know the full specs for a new-tiddler widget. With some help, I could likely upgrade the code to the required specs.

All of my original widgets were developed to address deficiencies in the core required to write my version of GTD. The features of my legacy $setfield widget have been superseded by the $action-setfield widget. The features of my legacy $mangletags widget I have now covered with the $action-listops widget (which also covers my legacy $makelist widget.) Still missing from the core are equivalents for the $x-maketid widget and, perhaps, the $iftid and $iftref widgets (although there are other ways of achieving this kind of logic -- notably the more advanced features of the $set filter.) I include this functionality as an option of my $x-setrefs widget, but I'm not sure this is for everyone (I prefer TextReferences -- therefore prefer the $x-setrefs widget to the $action-setfield widget.)

regards

[Jeremy Ruston]

Hi Tobias

On 10 Nov 2015, at 15:40, Tobias Beer <beert...@gmail.com> wrote:

Would the code-overhead be too much for a PR / did you already go down that road? It's just that I've seen this request pop up a few times now and I think it's perhaps core worthy to more silently create tiddlers that way.

I think people have successfully used the action-setfield widget to create new tiddlers silently. Not of course as flexible as Matabele’s widget.

Best wishes

Jeremy

[Tobias Beer]

Hi Matabele,

As Jeremy says:

 

I think people have successfully used the action-setfield widget to create new tiddlers silently. Not of course as flexible as Matabele’s widget.

Could you perhaps provide a quick overview of some of the features of or implementations based on your maketid action widget you would find most prominently missing as compared to using the core action-setfield?

Best wishes,

— tb

[Matabele]

Hi Tobias

The primary problem addressed by the $x-maketid widget is to do with the title of the new tiddler. A new tiddler requires a unique name, and this name gets generated only during the process of creating the new tiddler (by appending either a date/time stamp or an integer.) 

It is therefore impossible to write a button such as this with reliable results:

<$button>
<$action-sendmessage $message="tm-new-tiddler" title="My New Tiddler"/>
<$action-setfield tiddler="My New Tiddler" field1="one" field2="two" .../>
Create New Tiddler
</$button>

-- as the title of the new tiddler may not be 'My New Tiddler' (but may be something like 'My New Tiddler 1'.)

It is therefore necessary to set all of the values for the new tiddler either within the widget itself or via other widgets stacked around this widget which 'know' the title of the new tiddler. The $x-maketid widget gives multiple options for setting the title, tags and other field values and, where this proves insufficient, passes the name of the newly created tiddler via the parameter to a message to one or more $x-setrefs widgets, stacked around the $x-maketid widget.

The $x-maketid widget also allows for a new tiddler to be opened in edit mode (as for the tm-new-tiddler message), or created in the background (as for using an $action-setfield or set TextReference), or for navigating to the new tiddler in view mode.

The $x-maketid widget also provides for appending a date/time stamp to the title (in any specified format), for journal type tiddlers.

The $tags attribute of the widget allows for a subfilter to be applied to the list of tags copied from the template -- allowing tags to be added/removed/replaced etc.

These features together, allow for multiple similar tiddlers to be created reliably with successive clicks of the same button. This was a feature I required when populating folders for my version of GTD -- in this case, I wished to create a number of tiddlers in succession, the titles for which were contained in a list (in a data index.) 

Any other desired functionality can be easily added via additional attributes -- something that would be more difficult with the 'tm-new-tiddler' method.

In general, I also find the action widget method more straightforward and more easily understood than methods based around widget messaging.

regards

[Dave]

Thanks Matabele,

I'll try that out and let you know how it goes.

- Dave

[Tobias Beer]

Hi Matabele,

As I see it, the missing link is mostly the ability to silently create new tiddlers in a reliable way, missing as in "missing in the core".

The primary problem addressed by the $x-maketid widget is to do with the title of the new tiddler. A new tiddler requires a unique name, and this name gets generated only during the process of creating the new tiddler (by appending either a date/time stamp or an integer.) 

That makes sense.

So, the problem lies in having two widgets needing to know of the same unique title to use, one being action-sendmessage and the other action-setfield in your given example. I'm beginning to ask myself if — in these circumstances — a given widget could not be given the possibility to set a variable for its parent scope, so that we would do:

<$button>
<$action-sendmessage $message="tm-new-tiddler" title="My New Tiddler"/>

<$action-setfield field1="one" field2="two" .../>
Create New Tiddler
</$button>

Notice how now action-setfield does not specify any tiddler title. That is because action-sendmessage, specifically the tm-new-tiddler message would actually set the currentTiddler variable for the scope of its parent, the button widget, upon execution and thus avail the new title to any subsequent action-widgets.

 

The $tags attribute of the widget allows for a subfilter to be applied to the list of tags copied from the template -- allowing tags to be added/removed/replaced etc.

 

Unless you already have, perhaps a few demo examples would be great to illustrate your widget's workings like these. At the moment, those links in your wiki appear to either be broken or the target contents removed.

Any other desired functionality can be easily added via additional attributes -- something that would be more difficult with the 'tm-new-tiddler' method.

In general, I also find the action widget method more straightforward and more easily understood than methods based around widget messaging.

It's not the first time that I have read that statement, although I wouldn't know what it actually means... as I have not studied both enough to understand the limitations to how the core is indeed processing things action- or message-wise.

Best wishes,

— tb

[Matabele]

HI

On Wednesday, 11 November 2015 07:57:03 UTC+2, Tobias Beer wrote:

Hi Matabele,

So, the problem lies in having two widgets needing to know of the same unique title to use, one being action-sendmessage and the other action-setfield in your given example.

 Yes.

I'm beginning to ask myself if — in these circumstances — a given widget could not be given the possibility to set a variable for its parent scope, so that we would do:

<$button>
<$action-sendmessage $message="tm-new-tiddler" title="My New Tiddler"/>
<$action-setfield field1="one" field2="two" .../>
Create New Tiddler
</$button>

Notice how now action-setfield does not specify any tiddler title. That is because action-sendmessage, specifically the tm-new-tiddler message would actually set the currentTiddler variable for the scope of its parent, the button widget, upon execution and thus avail the new title to any subsequent action-widgets.

Passing values (from an action widget) for variables to the parent scope is a good idea -- setting the value of the <<currentTiddler>> is not, as this changes the target tiddler for simple references (like {{!!title}} -- used for 'New Here' buttons, for example.)

The current tiddler can be set by enclosing the whole button within a $tiddler widget, but:

-- I found this approach problematic when writing application buttons

-- the title of the new tiddler isn't known before the new tiddler gets created

I adopted the approach of passing the value through a parameter to the widget message. This approach becomes complicated when several widget messages are involved (as for my legacy widgets.)

The introduction of a new <<targetTiddler>> variable within the enclosing $button widget would be a tidier approach:

-- the value of this variable could then be set by any action widget (when specified)

-- and could then be used by any following action widgets by default.

This would also address the annoying necessity of having to re-specify the target when using a stack of action widgets with the same target.

regards

[Tobias Beer]

Hi Matabele,

 

The introduction of a new <<targetTiddler>> variable within the enclosing $button widget would be a tidier approach:

-- the value of this variable could then be set by any action widget (when specified)

-- and could then be used by any following action widgets by default.

This would also address the annoying necessity of having to re-specify the target when using a stack of action widgets with the same target.

I very much agree, targetTiddler would be a better choice of variable than currentTiddler, working somewhat similar to how --output in the node commandline sets the output directory for subsequent commands.

Perhaps a core function could ensure that all action widgets actually identify the target they act on in the exact same way:

$tw.wiki.getTarget(title);

...using title as the target, otherwise falling back to using the value stored in targetTiddler. Not sure if there are differences, but widgets would call that function with whatever attribute the user is asked to use for specifying the tiddler title, e.g. tiddler, $tiddler, or param. If targetTiddler was undefined, the function would eventually return currentTiddler.

Best wishes,

— tb 

[Jeremy Ruston]

Hi Tobias

 the tm-new-tiddler message would actually set the currentTiddler variable for the scope of its parent, the button widget, upon execution

I’m afraid that it isn’t possible for a widget to alter the value of a variable set by its parent. A widget can only set variable values for its own descendents.

Best wishes

Jeremy.

[Tobias Beer]

Hi Jeremy,

 

I’m afraid that it isn’t possible for a widget to alter the value of a variable set by its parent. 

A widget can only set variable values for its own descendents.

Would that be...

• by choice ...or...
  
• because it's actually, technically impossible (perhaps owed to scoping)

?

If it is scoping, I imagine there may be ways for functionally scoped variables to access / set a variables from the calling / outer scope? Admittedly, I have no idea as to the complexity of such accessors... or how design that in a "safe" manner.

Best wishes,

— tb

[Dave]

follow up report:

Hi Matabele, your x-maketid widget, combined with Eric's suggestion (in another thread) of macrocall turned out to be exactly what I needed:

<$button>
<$x-maketid  $title="50m Freestyle" date=<<now YYYY-0MM-0DD>>  tags="races"
text="\define event(what,when) <<races event:'$what$ $when$'>>
<$macrocall $name='event' what=<<currentTiddler>> when={{!!date}}/>"/>
new 50m Freestyle Race
</$button>

That allowed me to have a button that makes a tiddler with the race name and this race table (macro):

\define races(event:"event")
[[$event$]]
<table>
<$list filter="[tag[swimmers]sort[title]]">
<tr><td><$link><$view field="title"/></$link></td><td><$edit-text tiddler='$event$' field={{!!title}}/></td></tr>
</$list>
</table>
\end

where I can input the results without the refresh problem seeing as the tiddler being written to isn't the one that's newly opened (in view mode, not edit mode (yay!))