Convert post list widget to a general "directory" widget.


The post list widget created in needs to be generalized, as discussed in a comment there.

Create a "directory" widget for a generalized listing of child artifacts. For this initial ticket, it will rely heavily on defaults, assisted by an "archetype" indication. This initial version will not implement any sort of expression language.

  • The widget will be named mummy:directory.

  • By default, it will simply list the navigable child artifacts in a <ul> structure, sorting in ascending order by publication date, then in ascending order by title. (A future ticket will allow a sort-by attribute or similar to change this.)

  • It will use an optional group-by attribute, initially supporting either publication-date or publication-year. (Perhaps in the future an expression equivalent would be Even with an expression language, some fields might be difficult to access with expressions; what if we wanted to support both publishedOn and publishedAt? We may have no choice but to always support some keywords such as publicationDate.) Each value will support an optional preceding + or - to indicate ascending or descending order, respectively, e.g. -publication-year for reverse order by the year of the publication date.

  • It will use an optional archetype attribute, initially supporting a single value: blog. If this is present, no group-by attribute will be allowed (at least for this ticket) and behavior will be equivalent to that developed in (with improvements as necessary). Specifically it will handle sorting like GUISE-109: in reverse order by publication date, then in ascending order by title.




Garret Wilson
April 10, 2020, 3:41 PM

Note that the JSON API also uses an optional - prefix to indicate descending order, although there is no + prefix, opting instead to simply default to ascending order. I suppose we need to decide whether grouping automatically sorts in ascending order, or sorts in no particular order unless a sign is given. In this particular case users would probably expect ascending order by default, but there may be cases in which we merely accept the order given from the source (whatever that is).

Garret Wilson
April 10, 2020, 3:53 PM

Another thing to take into account is that HTML attribute names are case-insensitive. Something like <mummy:Directory groupBy="publicationDate"> won't be a problem in XHTML, but what happens when we support parsing HTML? Might we want to use group-by instead (or even lowercase mummy:directory)?

Angular.js for example will normalize directives, so that a foo-bar attribute is equivalent to fooBar in the model. We are already doing something similar when parsing (X)HTML metadata.

I suppose we need to follow suit, if we want this stuff to work in HTML as well. And since publicationDate is a "keyword" of sorts, not an actual variable, we'll need to use publication-date. But when we have an expression language, we'll want that to use the actual model name, e.g. ^{it.publishedOn} or some such.

Garret Wilson
April 10, 2020, 4:58 PM

With so many moving parts in this ticket, it just hit me that a major motivation of this feature was to group pages by year. So we'll need a group-by="publication-year" as well.

Garret Wilson
April 10, 2020, 9:54 PM

In the future we need to add a sorted-by attribute to indicate whether pages are sorted by title or by publication date or whatever. Currently unless a blog archetype is specified, the pages will be sorted by title.

Garret Wilson
April 16, 2020, 1:48 PM

We might as well simplify this so that by default (i.e. if a blog archetype is not specified) sorting is done the way it would probably be expected: in ascending order by publication date, then ascending order by title.



Garret Wilson


Garret Wilson




Fix versions