Buttons for switching between editing and displaying

#1

I’m trying to realize a inventory with TiddlyWiki.
Basic things are working, but now I’m stuck with moving items between containers/storages.

My first attempt was a select widget for selecting other containers/storages. It worked, but I was looking for a way to prevent the user selecting a wrong storage or container accidentally. So I tried to use an edit button which, after clicking on it, displays a select widget with all other containers. This works, too and also the save-button is being displayed right. Unfortunately it doesn’t work when one clicks on it.
A tiddler with (title) “yes” is being created instead. I think that this could only be a minor problem caused by wrong syntax.

Please have a look at https://mytemp-site-24.tiddlyhost.com, where a minimal copy of my current version resides.
Maybe it is designed the wrong way and one could do better - It’s my first try to dive deeper into TiddlyWiki :slight_smile:

Another thing which I noticed is that when I put details or description for the items into fields, it isn’t being displayed when I search for it.
Of course, I could put it in the text, too, but then I have to format each tiddler by hand and my (item-)template would be rather useless.

As ever, thank you in advance for any hints :slight_smile:

– Roland

#2

It looks like you haven’t made your wiki publicly accessible yet. You can update the permissions on a per-wiki basis from in your site dashboard:

image
image866×223 7.54 KB

A “default” search only looks into the title, tags, and text fields, but you can use the Filter search tab available in the $:/AdvancedSearch for broader (or more specific) search needs.

image
image947×251 17.6 KB

The search operator has an extended syntax that lets you specify fields to include or exclude from your search.

  • [search[keyword]] – the default search, equivalent to [search:title,tags,text[keyword]]
  • [search:title,list,myfield[keyword]] – searches only the “title”, “list”, and “myfield” fields
  • [search:*[keyword]] – searches across all fields in the wiki
  • [search:-title,tags[keyword]] – searches all fields except “title” and “tags”

These patterns will all work in any situation where you would use a filter—in Filter Search, but also in a $list widget or a list-links macro, for instance.

Hope this will help get you started!

#3

Thank you Emily, you are right - it was marked for private access only.
I thought that a “private” site hides it away from search engines and as long one knows the full URL it is still accessible - I was wrong and learned a bit more today :slight_smile:

Thank you for explaining the search mechanism in detail, too - now I know why my (standard) search “missed” some keywords. Will try to build a specific search, which searches in some fields, too :+1:

#4

You’ve discovered a key property of the list widget! List widgets let you optionally define a variable to represent each output of the filter—and crucially, if you don’t define an alternate variable, the list will default to using the <<currentTiddler>> variable. This means that within the list widget tags, <<currentTiddler>> won’t refer to the “parent” tiddler you’re currently viewing, and any functions that depend on that variable may break.

So what’s the current value of <<currentTiddler>>? You can always test this by pasting that variable within the list content, but let’s look at the $list surrounding your Done button (edited to use “match” for concision):

<$list filter="[{!!EditParent}match[yes]]" emptyMessage=<<LocEdit>>>
<<LocSave>>&nbsp;</$list>

This says:

  • Retrieve the value of the “EditParent” field.
  • If the value of “EditParent” doesn’t match yes, the filter has no results: display <<LocEdit>>.
  • If the value of “EditParent” matches “yes”, the filter has one result (= “yes”).
    The content of the widget (<<LocSave>>&nbsp;) is rendered once per filter result; <<currentTiddler>> represents the string being rendered (= “yes”).

When [{!!EditParent}match[yes]], we see the output of the LocSave macro:

<$button set="!!EditParent" setTo="no">Done</$button>

Here, the text reference “!!EditParent” works like {{!!EditParent}}: if you don’t specify the name of a tiddler before !!, it will default to <<currentTiddler>>. And as we’ve already discovered, the <<currentTiddler>> in this context is “yes”. So when you press the button, you’re setting the “EditParent” field of the “yes” tiddler to “no”—and if the “yes” tiddler doesn’t already exist, it will be created.

Luckily, we can fix this by specifying an alternate variable in the original list widget:

<$list filter="[{!!EditParent}match[yes]]" variable="editing" emptyMessage=<<LocEdit>>>

Now the “yes” output will be stored in <<editing>> instead of overwriting <<currentTiddler>>, and your button should work as expected.

Edit: Here’s an alternative solution with a slightly different approach:

<$list filter="[<currentTiddler>EditParent[yes]]" emptyMessage=<<LocEdit>>>
  • Here, I’m relying on a property of the field operator: “The syntax of a filter step treats any unrecognised filter operator as if it was the suffix to the field operator.”
  • “EditParent” isn’t a filter operator, so it will be treated like field:EditParent. → If the current tiddler has an “EditParent” field with value = “yes”, the filter will ouput the title of the current tiddler.
  • Unlike [{!!EditParent}match[yes]], this filter won’t change the value of <<currentTiddler>>, so we don’t need to specify a variable attribute for the button to work as expected.
#5

Thank you so much for your in-depth reply!
It’s very detailed and valuable for a beginner like me. It shows me my deficits in understanding the Filter and Widget mechanisms. It’s easy to achieve basic functions, but when it comes to sophisticated solutions, I quickly mess up.
Thanks to your explanation I will be able to solve my problem!

1 Like