◊(Local Yarn Code "View Ticket")

2019-04-07
21:14 Closed ticket [f580d194]: Need for “listings” functions to support series surfaces architectural problem plus 4 other changes artifact: eeb97d83 user: joel
20:58
Support article listings from cached HTML. Resolves [f580d194] check-in: e493f1c6 user: joel tags: trunk
17:47 Ticket [f580d194] Need for “listings” functions to support series surfaces architectural problem status still Review with 3 other changes artifact: 86c1dedf user: joel
17:47 Ticket [f580d194]: 3 changes artifact: da18f9c7 user: joel
2019-04-06
21:08 Review ticket [f580d194]. artifact: 953b2b06 user: joel
20:58 New ticket [f580d194]. artifact: 0dcc9561 user: joel

Ticket Hash: f580d19482db99f2541c19f926d2a840ec4dce97
Title: Need for “listings” functions to support series surfaces architectural problem
Status: Closed Type: Code Defect
Severity: Important Priority: Immediate
Subsystem: Resolution: Fixed
Last Modified: 2019-04-07 21:14:56
Version Found In:
User Comments:
joel added on 2019-04-06 20:58:06:

There should be tag functions available for use within the doc of a Series .poly.pm file that can call up listings of articles within that series.

However:

  1. These functions need to draw on the SQLite cache database, and right now the connection to that database is lit up from within the template — that is, after the doc has been rendered.
  2. I need to know what to do with these functions when rendering to something other than HTML. Will they ever be needed for LaTeX/PDF? More generally, will the series pages themselves ever be rendered to anything other than HTML?


joel added on 2019-04-06 21:08:39:

Re: #1 above, there are two approaches I see.

One, initialize the db connection earlier, possibly in tags-html.rkt (conditional on HTML being the current output target).

Two, define metas within a series that would govern how its child articles are displayed, and then call functions in the template based on those metas.

I’m leaning towards the first approach, because it gives author-me a lot more freedom in whether and where to put article listings. I could put them before, or between, or after other content in the series page. Or even omit them altogether, resulting in a series where you can’t see the child articles except by discovering them individually.


joel added on 2019-04-07 17:47:37:

If I do go this direction, I will need a way to protect the HTML strings from later being escaped by ->html in the template.

Right now I am thinking of enclosing the strings in a script txexpr to prevent them from being escaped, and an unfence tag that will strip the script tags out of HTML strings.


joel added on 2019-04-07 17:47:51:

Re: #2 above: the cache db only stores HTML right now so the listings functions can’t return anything except HTML.

Once I actually start working on the print side I can think about what the listings functions should return in that context, or whether I should just make them return empty strings.


joel added on 2019-04-07 21:14:56:

Resolved with [e493f1c6]:

  • spell-of-summoning! is now called from pollen.rkt if HTML is the target output format.
  • Listings functions return results inside a 'style txexpr to keep ->html from escaping the pre-cooked HTML strings.
  • New function unfence provided from from crystalize.rkt to strip <style> tags from HTML.
  • The SQLite cache now has a series_pagenode column for notes as well, just so notes can be filtered by series alongside articles in list-full/articles+notes.
  • New function here-output-path provided from dust.rkt, occasioned by need to allow listing functions to default to filtering based on the current pagenode.
  • Added 'style to the list of “block tags” in the setup module; this prevents it from being surrounded by paragraph tags.
  • Code docs updated to reflect the above wherever applicable.