Task state in ${} vs virtual page?

General
1

If I create a listing of all tasks like so:

${template.each(query[[
  from index.tag("task")
]], templates.taskItem)}

Any tasks with custom state are rendered like this:

* NOT STARTED page@123 task text

I.e., the task state box is never rendered, so I can’t change it from this listing. Tasks that just have default “checked/unchecked” state do render a checkbox, but it doesn’t link back to the checkbox on the original page.

This behavior is the same even if I render this task listing via a widget:

function tasks_widget()
  local content = ""

  for task in query[[from index.tag("task")]] do
    content = content .. string.format("* [%s] %s\n", task.state, task.name)
  end

  return widget.new(content)
end

${tasks_widget()}

However, if I create a virtual page in approximately the same manner:

virtualPage.define({
  pattern="all_tasks",
  run = function()
    local content = ""

    for task in query[[from index.tag("task")]] do
      content = content .. string.format("* [%s] %s\n", task.state, task.name)
    end

    return content
  end
})

All the tasks show up correctly and toggling state changes the state in the page where the task was defined. Why can’t tasks that are “embedded” on a page render correctly and have state changes link back to the original page?

On a somewhat related note, I see lots of errors where the client is trying to open a “real” page for my virtual all_tasks page (i.e., GET https://host:port/.fs/all_tasks.md). Shouldn’t Silverbullet ignore whatever it’s doing (syncing changes?) when the user is on a virtual page?

2

Yeah, this is a bug. Custom tag states are not very well supported or developed, to be honest. It’s a bit of a forgotten feature. Feel free to create a Github issue for it.

3

Thanks Zef. It looks like while regular checkboxes render correctly the changes aren’t propagated back to the original checkbox when they’re rendered inline versus being part of a virtual page. I.e. the difference between being a copy versus being a reference. I assume that’s a bug too? I’ll try to fix that as well.

4

No, that’s supposed to work. Are you sure it doesn’t? It did last time I checked (hah). If you have a specific case where it doesn’t let me know.

5

The rendered checkbox list element has to contain a Wikilink back to the original task. If multiple Wikilinks exist the last one is used.

1 Like
6

Right of course, I missed that part not being there. A wiki link to the .ref attribute has to be present, just like the templates.taskItem template uses.

7

@zef I tried the following:

/page1:

* [ ] a task

/page2:

${template.each(query[[ from index.tag("task") ]], templates.taskItem)}

And /page2 renders

* [ ] page1@2 a task

(withpage1@2 being a valid reference back to the checkbox)

If I check the box on /page2 and then click the page1@2 reference I’m taken to /page1 and the checkbox is unchecked. If I check the box on /page2 and reload /page2, the checkbox is still unchecked. It seems to me like the reference isn’t working properly, or am I doing something wrong?