Artifacts Associated With Ticket f580d194
Ticket change [0dcc9561] (rid 283) by joel on 2019-04-06 20:58:06:
- icomment:
There should be tag functions available for use within the doc of a Series <code>.poly.pm</code> file that can call up listings of articles within that series. However: <ol> <li>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.</li> <li>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?</li> </ol>
- login: "joel"
- mimetype: "text/x-fossil-wiki"
- severity initialized to: "Important"
- status initialized to: "Open"
- title initialized to:
Need for “listings” functions to support series surfaces architectural problem
- type initialized to: "Code Defect"
- icomment:
Ticket change [953b2b06] (rid 284) by joel on 2019-04-06 21:08:39:
- icomment:
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.
- login: "joel"
- mimetype: "text/x-fossil-wiki"
- priority changed to: "Immediate"
- resolution changed to: "Open"
- status changed to: "Review"
- icomment:
Ticket change [da18f9c7] (rid 285) by joel on 2019-04-07 17:47:37:
- icomment:
If I do go this direction, I will need a way to protect the HTML strings from later being escaped by <code>->html</code> in the template. Right now I am thinking of enclosing the strings in a <code>script</code> txexpr to prevent them from being escaped, and an <code>unfence</code> tag that will strip the <code>script</code> tags out of HTML strings.
- login: "joel"
- mimetype: "text/x-fossil-wiki"
- icomment:
Ticket change [86c1dedf] (rid 286) by joel on 2019-04-07 17:47:51:
- icomment:
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.
- login: "joel"
- mimetype: "text/x-fossil-wiki"
- icomment:
Ticket change [eeb97d83] (rid 301) by joel on 2019-04-07 21:14:56:
- icomment:
Resolved with [e493f1c6]: * <code>spell-of-summoning!</code> is now called from <code>pollen.rkt</code> if HTML is the target output format. * Listings functions return results inside a <code>'style</code> txexpr to keep <code>->html</code> from escaping the pre-cooked HTML strings. * New function <code>unfence</code> provided from from <code>crystalize.rkt</code> to strip <code><style></code> tags from HTML. * The SQLite cache now has a <code>series_pagenode</code> column for notes as well, just so notes can be filtered by series alongside articles in <code>list-full/articles+notes</code>. * New function <code>here-output-path</code> provided from <code>dust.rkt</code>, occasioned by need to allow listing functions to default to filtering based on the current pagenode. * Added <code>'style</code> to the list of “block tags” in the <code>setup</code> module; this prevents it from being surrounded by paragraph tags. * Code docs updated to reflect the above wherever applicable.
- login: "joel"
- mimetype: "text/x-fossil-wiki"
- resolution changed to: "Fixed"
- status changed to: "Closed"
- icomment: