On 6/5/2017 8:37 PM, Andreas Kupries wrote:
....

I am not sure that this would help him.
My reading of his request is that he wants to customize the page
generated by fossil itself [1].

That was my read too. The $64K question then is where such customization would be stored. Skins are per repository, and this is running outside of all repositories. There is the global settings location, of course, but that is per user and you might (sensibly) be running that server as a daemon-like user with no actual login, and possibly even no real home directory.

I suppose more command line options to fossil server is the easiest answer. Extending the very vanilla HTML emitted to optionally name a style sheet if named in a -CSS option, and to provide class documented and id attributes as appropriate, would get you most of the way. Of course, the file named as the style sheet must be automatically treated as named in the --files GLOBLIST so it can be fetched or none of this works.

I'd suggest allowing a file full of TH1 code as the scripting escape to provide hooks to compute additional details per repository listed, but I'm not sure how safe that would be. Perhaps offering an option that names a collection of well-known fields to include named with single letters would be sufficient for most cases. Something like --details Lnd to also include the Logo image, the project name, and the description. There are a bunch of things in the /stat page that would sound tempting to include, but unless the stats items are cached somewhere, that could have a huge cost at the server for page fetch in a folder with a lot of repositories. Logo, name and description are all easy, and likely have a fair bit of value. Project ID is easy, but likely only interesting to us internals geeks. Age, number of commits, number of open leaves, comment of latest commit, names of open branches, owners first pet's name, are probably harder.

If the --details option is used, the page could be a table and use the same sorting trick available to the ticket reports, which appears to work on any number of table columns without any coding changes.


....


I like the idea in general. It could completely eliminate the need for cron jobs to generate an index file, without a huge amount of configuration work.

--
Ross Berteig                               r...@cheshireeng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602

_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to