Newbie here! Here is a question.

[Nuryana Panaligan]

Well, I have two fields. Due for tasks, and schedule for events. I want to appear both fields on a single list, where it is sorted by date.

Example:

Tiddler Task A, the input on due field is 2015-12-25. Tiddler Task B, the input on due field is 2015-12-27. Tiddler Event A, the schedule field is 2015-12-26(0800-1700). Tiddler Event B, the schedule field is 2015-12-30(All Day)

The list would look like this.

Tiddler Task A I 2015-12-25

Tiddler Event A I 2015-12-26(0800-1700)

Tiddler Task B I 2015-12-27

Tiddler Event B I 2015-12-30(All Day)

Thank you for answering.

[Tobias Beer]

Hi Nuryana,

Welcome and smooth sailing!

I would recommend you use the same DateFormat

as TiddlyWiki itself does for the modified and created fields, e.g.:

YYYY0MM0DD0hh0mm0ss => 20151217181532 or just 20151217

This will allow you to properly use the ViewWidget to output those dates with any date formating you desire.

As for your list, you simply use a.... ListWidget (or list transclusion as below) alongside a template, e.g.:

<dl class="due-and-schedule">
{{{ [tag[foo]] ||$:/_my/templates/due-and-schedule}}}
</dl>

And then: 

title: $:/_my/templates/due-and-schedule

<dt><$link><$view field="title"/></$link></dt>
<dd>''due:'' <$view field="due" format="date"/></dd>
<dd>''schedule:'' <$view field="schedule" format="date"/></dd>

The above uses a definition list to group the fields with their titles, so

• dl — the definition list wrapper
  
• dt — a definition term (here the title wrapped in a LinkWidget to make it a clickable link)
  
• dd — its definition(s)

Notice how the dl is not part of the template.

While that's not actually needed, it is semantically more correct,

otherwise you would create as many definition lists as you would have items,

rather than one list that contains a given number of terms and their definitions.

Based on the class due-and-schedule assigned to the dl

you can further style your list using custom css stylesheets.

Best wishes,

Tobias.

[Eric Shulman]

On Thursday, December 17, 2015 at 9:53:05 AM UTC-8, Tobias Beer wrote:

Hi Nuryana,

I would recommend you use the same DateFormat

as TiddlyWiki itself does for the modified and created fields, e.g.:

YYYY0MM0DD0hh0mm0ss => 20151217181532 or just 20151217

This will allow you to properly use the ViewWidget to output those dates with any date formating you desire.

As for your list, you simply use a.... ListWidget (or list transclusion as below) alongside a template, e.g.:

The problem is how to *sort* the list by *two different fields* ("due" and "scheduled"), so that both Task and Event tiddlers are shown in the same date-ordered list.

What is needed is a way to specify several fields to sort by... something like "[sort[due | schedule]]" which would sort using the "due" field if it exists, OR the "schedule" field (if no 'due' field is present).  This syntax could also be extended further to allow multi-level ("AND") sorts using something like "[sort[A & B]] where all items are first sorted by "A", and then within each value of "A", items are sorted by the value of "B".

Of course, there could be some complexity if mixing of the syntax is permitted.  For example:  "[sort[A | B & C]]" would mean "sort by A (if present) or sort by B, then C if A is not present".  I'm not sure it's necessary to take it to this level, but it could be done.

thoughts?

-e

[Tobias Beer]

Hi Eric,

 

The problem is how to *sort* the list by *two different fields* ("due" and "scheduled"), so that both Task and Event tiddlers are shown in the same date-ordered list.

Ah, I totally overlooked that. This approach should do:

http://doublesort.tiddlyspot.com

As for extending the core sort filter, that would be great.

I'd simply do:

sort[foo !bar baz]

Meaning:

• sort by field foo in ascending order first
  
• then, for whatever discrete buckets we have for foo, sort bar in descending order
• eventually, based on the buckets for bar, also sort by baz in ascending order

I would also very much appreciate if we would cut all the different sort filters and allow for the one core sort filter to specify the sort mode e.g.:

sort[foo(cs) !bar(n) baz(ncs)]

I'm not at all a fan of having a bucket full of filters doing the same thing, slightly differently.

This highly impinges on flexibility and bloats things for no reason I can discern... except a minuscule performance gain.

It may be necessary to tell the sorting where to put blanks (or titles actually not having a field). So...

sort[foo(cs ^) !bar(^) baz(ncs)]

Here, the ^ could indicate that we want them up top, otherwise they'll be at the bottom.

Best wishes,

Tobias.

[Tobias Beer]

Actually, correct me if I'm wrong, but sorting by multiple criteria is far simpler than initially thought.

All you need to do is reverse the order in your filter expresion, from weekest sort criteria to strongest, e.g.:

{{{ [tag[Composers]sort[givenname]sort[surname]] }}}

Will have the output eventually sorted first by surname and then by givenname.

I have updated the doublesort demo accordingly:

http://doublesort.tiddlyspot.com/

Best wishes,

Tobias.

[Eric Shulman]

On Thursday, December 17, 2015 at 4:24:59 PM UTC-8, Tobias Beer wrote:

Actually, correct me if I'm wrong, but sorting by multiple criteria is far simpler than initially thought.

All you need to do is reverse the order in your filter expresion, from weekest sort criteria to strongest, e.g.:

{{{ [tag[Composers]sort[givenname]sort[surname]] }}}

Will have the output eventually sorted first by surname and then by givenname.

The problem in the OP is still unsolved.  He doesn't want a multi-level sort.  He want to have a single list, sorted by either "due" OR "scheduled"... not "due" AND "scheduled".  This can't be done using the current sort[] filters.

Actually, I think the best solution would be to use the same field name is both Task and Event tiddlers (e.g., "assigned_date").  Then, it becomes trivial to just sort by "assigned_date" rather than trying to get values from two different field names for the same sort.

-e

[Tobias Beer]

Hi Eric,

 

The problem in the OP is still unsolved.  He doesn't want a multi-level sort.  He want to have a single list, sorted by either "due" OR "scheduled"... not "due" AND "scheduled".  This can't be done using the current sort[] filters.

I think I understand your point now. Here's a demo I had to make to realize what you mean with OR sorting:

http://doublesort.tiddlyspot.com/#DueAndSchedule

TL;DR;

Summing up that general advise:

1. use core date formats for custom date fields
2. whether or not a date is all day is computed by the length of the entered date, not a suffix
3. a due date should always be later than a scheduled date
• the other case should only occur when you're overdue
  
• your examples seem to demonstrate that
• for this reason, your sorting should always take the due date when you're overdue
  
• even if you want a scheduled date to take precedence

Truly, this date handling stuff for GTD-style planing is anything but trivial.

There is a loooong list of issues around this and that is why there are things like MGSD, GSD5, etc...

1. your problem is not only about some filter that can sort by, say a scheduled date and only then a due date
• as you say: I want both fields on a single list, where it is sorted by date.
• well, there is no such "date" (field) to sort by: the date you refer to is temporarily computed
• you not only want one field should the other not exist, you possibly also want to sort by always the lower of both!
• interestingly, if the due date was before the scheduled date, then you did some mis-planning
• this should only be the case for tasks that are overdue, and so they should possibly always be up top
• i.e. the due date here should take precedence because it is before the scheduled date
• I'd prefer a separate "overdue" list where only those where due < today && scheduled < today are shown
• and I don't think there's a filter for that
• so, you really have 3 dates:
• optionally, a due date — when to hand something in (may not exist)
• if today is past the due date, we're overdue
• optionally, a scheduled date — when to do something
• if this was ever after the due date, then we're doing some awkward "overdue management"
• in other words, this should only occur if we're already past the due date
• a "target date"
• being computed, not manually entered
• and then I am not so sure what to do, because...
• when you're overdue, where do you show these items?
• at the due date?
• at some even more overdue scheduled date?
• imho, they should not be on the same task list but be a separate list of overdue items
• sorted by whatever you want, possibly switchable
• by default, sort by due date, but allow to switch to sort by scheduled date
• if you want them on your main task list, overdue should always be up top, in red
• which field should take precedence?
• possibly the scheduled field since...
• if we took the due field, then we'll not properly sort by how things are scheduled
• however, if we're overdue, then we should possibly sort by due date
• this is why overdue needs to be separate from the main list
• it's also why mixing due and scheduled is confusing, make it two lists!
2. however, you possibly not only want this sorted by target date
• chances are, you should also (always) display the "target date"
• at least indicate which of your date fields actually is your target date
• and also show the other date, if present
• perhaps you could simply make the field that is your target date bold
• this would currently require six states, one to check if the field exists and a flag as to whether it's the target date
• [if we have a due date: <not being the target date> / <being the target date> ]
• [if we have a scheduled date: <not being the target date> / <being the target date>]
3. we cannot, currently, tell the sort filters where to put empty items
• meaning: tiddlers that either don't have a due field or a scheduled field
• this is problematic, because in this case, we possibly always want them last, not first
• if there was no scheduled field, they are somewhat "unscheduled", although due
• if there was no due field but a scheduled field they should sort just fine
• assuming that the scheduled field is generally what we sort by
• i.e. "when to next work on what"
• so, I opened an issue for that:
  
  #2137 sort filters and empty value position
  https://github.com/Jermolene/TiddlyWiki5/issues/2137
  

With all of the above complexity, here's why I much prefer and advocate reminder tiddlers (and why we have GTD editions)...

• for me, reminders should be their own tiddlers with a date, consciously set
• they should relate to a task tiddler either via tagging or a reference field
• a due date would perhaps be set at the tiddler to which the reminder relates
  
• the moment you set the due date, you may actually want to "schedule" a reminder
• otherwise the task is unscheduled
• alternatively, a due date could and perhaps should be a special form of a reminder tiddler that has a given tag or field set
• if you deleted a tiddler for which you have reminders, then that reminder is in limbo
• then you use different lists for your task tiddlers
• scheduled:
• tiddlers having an associated reminder at all
• sorted by urgency, i.e. by how close the reminder date is with respect to today
• using color to hint at the delta between now and the reminder date, overdue being red
• unscheduled
• tiddlers sorted by due date that have no reminders associated
• so, you do not try to make one big messy list, but instead...
• consciously look at things with respect to whichever sequence is most important
• if there is something overdue, always check first
• if you have unscheduled tasks, see if you want to do some scheduling

Personally, I think this the pattern for how a reminder list should look, overdue being red and today being 2015-12-18:

       2015-12-15 foo (due: 2015-12-18)
                  do something

  8:00 2015-12-16 bar (due: 2015-12-20)
                  do another thing with loads of text

                  mooooaaaaar text
                  and then some
                  

 14:00 2015-12-18 baz
                  also do this

                  

 14:00 2015-12-20 mumble

So, foo, bar, baz and mumble would be task tiddlers but the dates to the left are actually dates stored at distinct reminder tiddlers and the reminder text, should one be defined, is the reminder tiddler's text. Because, for one, you can have a number of reminders per task tiddler, not just one.

If due dates were also reminder tiddlers, then the list would look like this:

       2015-12-15 foo (due: 2015-12-18)
                  do something

  8:00 2015-12-16 bar (due: 2015-12-20)
                  do another thing with loads of text

                  mooooaaaaar text
                  and then some

       2015-12-18 foo (due)
                  go celebrate!

                  

 14:00 2015-12-18 baz
                  also do this

                  

 14:00 2015-12-20 mumble

       2015-12-20 bar (due)

                  Now, go hand it in!

So much for reminders and dates. :D

Best wishes,

Tobias.

[Tobias Beer]

With the above considerations, I think OR filtering should work like so:

[sort[scheduled due]]

Meaning:

• sort by scheduled
• or due (should scheduled not be defined)

[sort[scheduled due foo]]

Meaning:

• sort by scheduled (if defined, otherwise...)
• by due (if defined, otherwise...)
• by foo

However, what we really want is this:

[sortn[< scheduled due]]

Meaning:

• sort by: the smallest value of either due or scheduled, if both are defined otherwise...
• by scheduled (if defined, otherwise...)
• by due

So, for three fields it would be...

[sortn[> foo bar baz]]

Meaning:

• sort by the greatest value of foo, bar or baz (if at least two are defined...)
• otherwise by foo (if defined, otherwise...)
• by bar (if defined, otherwise...)
• by baz

The corresponding sort modes, e.g. sort sortn, sortcs, sortncs, come on top of all that and apply to all fields.

Best wishes,

Tobias.

[Nuryana Panaligan]

Thank you for the tips. Sorry for Late Reply.

Also, sorry for the misunderstanding. The Tasks and Events have no relationship at all. For example. Task A is to repair my bike. Event A is a get together. Task B is to buy a new bag. Event B meanwhile is a national holiday.

[Matabele]

Hi

In that case, the simplest method would be to separate the 'schedule' field into two parts -- a 'due' field (like for tasks) and a 'duration' field -- sorting by 'due' would then be trivial.

regards