On Sun, Aug 30, 2009 at 4:42 PM, James Gruessing <[email protected]>wrote:
> *1) Removing all inline injected CSS and Javascript*
> I believe that declaring all objects within a page with the appropriate
> classes and id's, and handling all Javascript functions and events in a
> completely event-based manner is the best possible way, this will assist in
> code-separation and will also help in dealing with degradability and
> compatibility. At present CSS and page styles are scattered over several
> areas, and keeping all styles, colours etc in the one area.
>
Amen! IMO the UI "should" be done using mostly JS (e.g. via jQuery or
similar), however, that would break "lesser" browsers, and IMO they are an
important (or at least not minimal) consideration for fossil. So... as much
as i'd like a "real" UI (e.g. google mail), i'd hate to see fossil move that
direction.
Ideally (and longer-term), i think we could/should implement JSON interfaces
into/out of fossil, so that we could write AJAX apps on top of fossil. With
that in place, multiple WUIs could be created using one's own favourite
JavaScript library (*cough*jquery*cough*). i've been looking at C libs
lately for adding some JSON output support to fossil (e.g. timeline/commits
data), but the open source JSON-generation C libs i've looked at "just don't
do it for me," and i haven't yet settled on one (i don't want to implement
one if i can avoid it, though it might be useful to implement a custom one
on top of the fossil blob data type, to take advantage of the memory
management).
> *2) Solving future Internationalisation (i18n) and Localisation (l13n)
> issues*
>
i think the biggest hurdle here is the sheer amount of "user text" which is
in the code. Most of the text is inlined using a custom markup, e.g. from
src/wiki.c:
static int check_name(const char *z){
if( !wiki_name_is_wellformed(z) ){
style_header("Wiki Page Name Error");
@ The wiki name "<b>%h(z)</b>" is not well-formed. Rules for
@ wiki page names:
@ <ul>
@ <li> Must not begin or end with a space.
@ <li> Must not contain any control characters, including tab or
@ newline.
@ <li> Must not have two or more spaces in a row internally.
@ <li> Must be between 3 and 100 characters in length.
@ </ul>
style_footer();
return 1;
}
return 0;
}
that gets pre-processed via an app DRH wrote, and output via the internal
i/o API. Note the custom printf-specifiers, too (e.g. "%h(z)", above).
Also, all help for commands (e.g. fossil help commit) is stored as C++
comments, which get preprocessed as well.
Porting fossil to be "i18n-ready" would be a major undertaking.
*3) Creating a better look and feel*
> Not only for the Fossil website, but also for the default installlation. I
> would love to look at creating a look and feel. I'd also look at doing
> things like better representation of diffs, look at simple yet effective
> syntax hi-lighting, as well as making the editor for templates a little
> easier to use.
>
:-D
> Question: Would it be feasible to implement a very basic search function of
> documents in the wiki?
>
i think the biggest problem there is that the wiki is stored as compressed
diffs. To do a real search, one would have to decompress every version of
every page and perform the search on it. You could limit it to only the
latest versions, but it's still got to reconstruct the page before it can
perform the search. It could stuff that into an sqlite3 :memory: (or temp)
db and perform the actual search from there.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
