On Sun, Jul 15, 2012 at 9:40 AM, Gary_Gabriel <
[email protected]> wrote:
> 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.
There's no release timeline, so little pressure (unless it's coming from
you ;). Feel free to not be breif!
>
>> Versioning- the Munich discussions pointed out that custom pages such as
> download pages are not versioned to avoid versioning binaries.
at the moment it just handles external files fed in via the command line. i
was looking at the embedded docs to see if i could run those through th1,
but there's a lot of other logic going on there which i'd likely break. If
embedded docs could run th1 we'd already have some form of dynamic pages
(i'm not suggesting that we need to change that - this change would likely
break some stuff).
>
>> 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.
>
That's the goal, essentially. Once i write a custom page, i'd like to be
able for you to copy it into your repo. Whether that's going to happen via
sync (which the embedded docs do already) or something like the current
config push/pull, or via copy/paste, i don't yet know.
> 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.
i think it's likely that embedded docs won't get this feature, at least not
yet. It IS worth considering, but there is major room for backwards
incompatibility. Last night i did some minor refactoring which should ease
the path here (e.g. disable certain TH1 processing features when running
embedded docs, like disable the expansion of $vars which are not inside a
TH1 block).
> 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:
> ....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>
Good point. Speaking of TCL: i haven't yet looked at tcl for scripting
purposes, but it is certainly on the list of todos. th1 has everything one
really needs, but it is not well-suited to writing larger apps (e.g. when
it dies it often just died without telling us where, which means manually
scanning through all the code to find the error). tcl is a full-featured
language and will certainly be a big asset in terms of getting server-side
scripted pages implemented.
> 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.
Not necessarily - they can be done 100% server side OR 98% client-side
(where the server just submits a stub HTML file containing JS which then
loads the rest of the content). Insofar as feasible i would like to make
it possible to access as much of the functionality as possible from either
the client or server side. As of yesterday/this morning th1 script has
access to the GET/POST environment, the database, and an output buffering
layer (your merging example is a case where the buffering layer is useful),
so it's quickly becoming more useful for this (and these parts can be used
with the existing header/footer mechanism - my local repo now has
th1-fetched db data scattered around my header).
> The user generates them himself and stores them accordingly. Enabling TCL/
> Jim supports a merge capability as well as system of document generation.
>
The merge would be in the form of functions which load/render content, e.g.
something like:
import_doc doc_identifier ...args...
import_docs { doc1 doc2 doc3 ... }
which is just a different syntax than what you demonstrated above. We could
of course add a layer around that which generates section numbers and such:
sec_push
import_doc ...
sec_push # subsection
import_doc ...
sec_pop
sec_pop
things like that should be easy to do once the basics are all in place.
> Thanks for current news and a view on the development- Gary Gabriel
>
My pleasure! Note that nothing at all is set in stone at this point - i'm
just kind of feeling my way along and seeing what happens. Not all of it is
useful, but certain parts are turning out to be.
Thanks for the feedback, Gary,
Before i go, here's an example of what the th1 query API now looks like:
[stephan@host:~/cvs/fossil/fossil/src]$ cat q.th1
<th1>
catch {
set stmt [query prepare {
SELECT login, cap, cexpire, mtime FROM user
WHERE uid<? AND cexpire IS NOT NULL
AND mtime IS NOT NULL
}]
puts "stmt ID=$stmt\n"
query bind int $stmt 1 10
set sep " : "
for {} {0 < [query step $stmt]} {} {
puts [query col string $stmt 0] $sep
puts [query col time $stmt 2 {%Y%m%d @ %H:%M:%S}] $sep
puts [query col time $stmt 2 {%Y%m%d @ %H:%M:%S} {+10 years}] $sep
# puts [query col time $stmt 2 %s] $sep
puts [query col time $stmt 3 %s unixepoch] $sep
# puts [query strftime %s [query col string $stmt 3] unixepoch]
puts [query strftime %s [query col string $stmt 3] unixepoch] $sep
puts [query strftime {%Y%m%d @ %H:%M:%S} [query col string $stmt 2]
{+10 years}] $sep
puts "\n"
}
query finalize $stmt
return 0
} rc
if {0 != $rc} {
puts "ERROR: $rc\n"
}
puts "Done!\n"
</th1>
[stephan@host:~/cvs/fossil/fossil/src]$ f th1 q.th1
stmt ID=1
stephan : 20130714 @ 06:11:51 : 20230714 @ 06:11:51 : 1320445020 :
1320445020 : 20230714 @ 06:11:51 :
json-demo : 20130211 @ 19:29:25 : 20230211 @ 19:29:25 : 1319211587 :
1319211587 : 20230211 @ 19:29:25 :
Done!
--
----- 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
