Hi Stephan,
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)...
Thanks- looking forward to it. You're working under challenging
conditions and a short fuse. Doing justice to that; I will keep any
comments short.
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
);
Versioning- the Munich discussions pointed out that custom pages such as
download pages are not versioned to avoid versioning binaries.
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 think you hit the essential items.
To summarize my understanding so far; correct me if I'm wrong.
1) Embedded Docs and Custom Pages support project documentation and
configuration as a minimum requirement. Templates reduce the generation
effort. They also enable other systems to write docs as embedded or custom.
2) Generation and assembly of the Embedded Docs and Custom Pages
supports the system with an infrastructure of templates and a system to
automate generation.
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.
Merge. Experience has shown that a rather simple document merge fulfills
80% of the requirements, but Merge is essential. In the example you use
js for the merge. Tcl could leverage existing code at this point. Example:
# Configuration_File_for Doc1
<tcl>
# Doc1 contains Doc1.1, Doc2.2, Doc3.2. Merge the contents of these
documents in this order to generate the Custom Page.
# Configuration_File contents
Metadata
Doc1_css Doc1_css_Path
Doc1_header Doc1_header_Path
Doc1_footer Doc1_footer_Path
Doc1.1 Doc1.1_Path
Doc2.2 Doc2.2_Path
Doc3.2 Doc3.2_Path
</tcl>
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
See merge above.
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.
Then if I have understood correctly; Embedded Docs and Custom Pages use
a minimum infrastructure of TH1 and js (jquery) to manipulate the pages.
The user generates them himself and stores them accordingly. Enabling
TCL/ Jim supports a merge capability as well as system of document
generation.
Thanks for current news and a view on the development- Gary Gabriel
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
