Yes, this was my usercase. Specifically I would like to configure the page generated by the `—repolist` option in `fossil server`. Whilst the `—files GLOBPATTERN` is helpful in so far as generating an alternative html page, I really wanted to be able to use a config option in `fossil server` to generate an HTML page which included the repolist (as well as some external files/images).
As a server option it does not need to be versionable or distributable - i.e. I am happy for it to reference a configuration file of .html, images etc in a configuration directory that sits alongside all the fossil repos. JP > On 6 Jun 2017, at 06:07, Ross Berteig <r...@cheshireeng.com> wrote: > > > > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
