Hi, all,
i've been hacking the th1 bits (fossil's built-in scripting engine) all
night and we're a step or two closer to being able to implement one of the
types of custom pages (which, i think, will form the basis of at least one
of the other types)...
Before i dive into this and make a mess of it, i'd like to be sure i've got
a structure we can use, synchronize, and whatnot, and that's where you all
come in...
Conceptually, the db structure for a custom page might look like (assume we
are not versioning these for the time being, but there is nothing stopping
us from running versioned blobs through the th1 engine):
create table custom_page(
name text unique not NULL,
mimeType text default "application/x-fossil-th1", // some types need to
be served w/o a wrapping page, e.g. JS
content text // page content,
layoutPage text default NULL, // name of a layout template (see below)
runMode int default 0 //<0 = CLI only, >0 = HTML only, 0 = both
);
Let's ignore for the moment things like recording who changed what when.
The initial draft will be without versioning, and we have a couple
different options for versioning (in the filesystem, as wiki content, or
extending the fossil protocol (last resort!)). Keep in mind, too, that we
could also extend embedded docs to support th1 (i don't think(?) they do
right now?), which gives us yet a different option for custom pages.
Layout templates...
create table page_layout(
name text unique not NULL,
header text default NULL,
footer text default NULL,
addBanner text default NULL, // name/id of a configured ad banner. would
prefer to handle this via nestable layouts
// sidebars are a consideration, but not a high-priority one... thay
could be done much more generically with nestable layouts
side1 text default NULL,
side2 text default NULL
);
i'm not really happy with that, but it's a starting point. i'm _not_
specifically aiming for something as flexible as newer wordpress versions
and similar UIs, but if it's easy enough to do then why not? Nestable
layouts (not modeled above) would ideal because they allow us to genericize
a great deal (i.e. be more flexible).
Layouts are th1-capable and are more generic than the current header/footer
mechanism (which could be re-implemented on top of this). Insofar as
possible, i would like to make layouts and pages nestable so that we can
create libraries of functionality and include them from multiple pages,
e.g. via this hypothetical th1 code:
render_snippet MyPageName
render_snippet my.css
render_snippet /lib/jquery.min.js (names need not be restricted to
alphanumeric)
which would dump that page's contents into the currently running page.
The default layout templates would essentially mimic what the HTML UI does
now: wrap up a central content area with a site-wide header and footer,
augmented by page-specific menus (possibly yet another API we need to add
to th1). Alternate templates would be provided for common cases like
serving content as-is (with no HTML wrapper), e.g. serving JS or CSS code.
Custom pages are not just pages, but also CLI commands. TH1 can be used in
CLI mode to process scripts and we can use that to:
a) run custom pages from the CLI (if they don't output too much HTML it
might even be usable as-is).
b) add alternate implementations for a custom command for CLI and HTML
modes.
c) pass scripts to fossil, giving clients some degree of scripting control
over it using its own built-in engine (i.e. "also works on Windows").
So, for example, we could do the following from the CLI:
fossil custom MyPage --nowrap
(--nowrap = CLI option to elide the header/footer, maybe make this default
in CLI mode)
fossil custom MyPage-CLI # a version of MyPage with no layout tempate
and generating no HTML
fossil custom timeline --limit=3 --after=2012-01-01 ...
(th1 now has access to the CLI flags)
What we need first, though, is a decent, marginally generic mechanism for
specifying/controlling:
a) the internal structure and metadata needed for each custom command/page
b) layouts: wrapping individual pages/commands/snippets within one another,
ideally arbitrarily deeply.
i very much welcome your opinions on the topic!
Happy Hacking! (Back to th1...)
PS: while i keep saying th1 here, if we get the infrastructure right then
integrating TCL/Jim/whatever would simply be a simple matter of a small bit
of glue gode and setting the mimeType field for a given page to (e.g.)
application/x-fossil-tcl.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
