[Patch] More predefined TH1 variables
(1) By george on 2020-02-23 23:07:47 [link] [source]
Hello!
Documentation on custom skinning says that
New predefined values are likely to be added in future releases of Fossil.
I suggest three additional TH1 variables for the /doc webpages. The corresponding bundle is also available.
What do you think? Please consider merging into the mainline.
(2) By Florian Balmer (florian.balmer) on 2020-02-24 09:25:33 in reply to 1 [link] [source]
Some comments on the code:
- It seems
rid
is only valid to use in a query ifvid!=0
, i.e. not for/doc/ckout/...
or/uv/...
pages. - The code should conform to ANSI C-89, i.e. variables should be declared at the beginning of the scope.
(3) By george on 2020-02-24 11:29:20 in reply to 2 [link] [source]
Thank you for the observation. Fixed.
(4.1) By Florian Balmer (florian.balmer) on 2020-02-24 13:47:58 edited from 4.0 in reply to 1 [link] [source]
Meanwhile I wonder if this is a "security risk", since the information from the rcvfrom
table is usually only available to setup users, and maybe administrators?
And, to give readers a better overview of the document history and contributors, linking to the /finfo
page may be more useful? (Edit: because the rcvfrom
table is completely different for a local clone, for example.)
(5) By Richard Hipp (drh) on 2020-02-24 13:48:46 in reply to 4.0 [link] [source]
Yeah. I'm inclined to avoid exposing implementation details like this without a really good reason. I'm also concerned about feature-creep.
The OP has not (yet) made an argument for why these TH3 enhancements are needed or are useful. That needs to happen prior to giving this patch deeper consideration.
(7) By Richard Hipp (drh) on 2020-02-24 14:10:13 in reply to 5 [link] [source]
A capability I would like to see added to embedded documentation is the ability to show the date and time when the document being viewed was last edited. I can think of several ways to do this:
This could be accomplished with a new TH1 variable that is recognized by the footer, causing the footer (or the header) to show the "last modified YYYY-MM-DD" message. Perhaps the new TH1 variable is called "document_date" and only exists when showing embedded documentation, so the TH1 code in the header and/or footer would only show the modification date when displaying embedded documentation.
Enhance the /doc URL handler to show the last modification date someplace (perhaps associated with the document title somehow) but only if the administrator turns on a setting. Perhaps that setting could be a GLOB pattern list specifying the specific documents to which it applies.
Update the convert_href_and_output() routine so that provides an additional $VARIABLE for the last modification date, or perhaps some special markup, like
<last-modification-date>
.
A similar nice-to-have would be the ability to have a link to the complete edit history of the document.
(8) By Warren Young (wyoung) on 2020-02-24 19:10:23 in reply to 7 [link] [source]
This could be accomplished with a new TH1 variable that is recognized by the footer
Maybe more than a simple scalar, something closer to stat(2)
output, or in this case, to /info
or /finfo
. That is, a list or hash of data about the artifact being rendered for use in TH1.
Enhance the /doc URL handler to show the last modification date someplace (perhaps associated with the document title somehow) but only if the administrator turns on a setting.
Eh, this feels more like a skinning issue, thus something for TH1, not a checkbox to be enabled. It's akin to the current document rendering time feature.
A similar nice-to-have would be the ability to have a link to the complete edit history of the document.
That should be easy to construct in TH1 already using a /finfo?name=
URL, assuming TH1 knows the current document's file name.
(6) By george on 2020-02-24 14:02:38 in reply to 4.0 [source]
I wonder if this is a "security risk"
Fair point. But the information from these variables is consumed by the header/footer of a specifically customized skin (which only the setup user can apply) or by the document itself, if th1-docs setting is switched on (in which case the author of a document should decide).
linking to the /finfo page
I do that already in my custom skin, but this is the different use-case. Consider the need to form a printer-friendly webpage that shows precise version information of the underlying source file.