On Fri, Apr 15, 2011 at 1:08 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > On Fri, Apr 15, 2011 at 8:05 PM, Ron Wilson <ronw.m...@gmail.com> wrote: >> >> Are you asking how to update all your wiki pages, or just replace the >> markers when a wiki page is displayed? > > Just to replace them. e.g. at the top of the page (or in my header, or > whereever) define some variables: > star1 = "(*)" > star2 = "(**)" > star3 = "(***)" > and then replace those strings in my page with their variables. >> >> If when a wiki page is displayed, you could put Javascript in the page >> footer to do this. > > Good idea, but that would be way overkill for what i'm doing (so is th1, but > i'm now curious if/how it can be done).
Hi, Last time I looked, wiki pages are not subject to any TH1 interpretation. Only a handful of places in fossil source are. This is probably good for security, since, you generally don't want "arbitrary" people being able to run code on your site. That said, I've been thinking about the idea of implementing a generic "report" type to fossil for some time. It would follow the same form as a wiki page, but would allow any generic TH1 to be executed. For that reason, it would have its own permission so as to prevent unauthorized users from creating and or running reports. The idea behind reports being that I might have automated testing infrastructure that I want to add tags to check-ins that passed code compilation tests and/or unit tests, and then I'd have a report that would show me the most recent passing check-in, and possibly even some statistics about who commits the most broken code, for example. It would require some additional functions in TH1 to allow examining the repository state in more detail. You can see a couple of the functions that I started with in the 'th1_fossiltag_cmd' and 'th1_wikicontent_cmd' branches. (The wikicontent command is easily usable to create default "forms" for ticket creation, and I've done as much on a private repository in the past. I've also used the fossiltag command for that purpose.) I haven't gone further with it due to philosophical/practical disagreements wrt to the best way to expose the repository state. Nevertheless, it's something I'm still considering since I have a practical need for it. Of course, I'm also still waffling on whether or not such functionality is even worthwhile to have in fossil core. I personally want a more functional web interface, though I don't have a deep desire to make it "Web 2.0" with AJAX and JSON. -B _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
