Re: [sfWiki-devel] web formatting

[Todd L. M. <tm...@ha...>]

	First, a quick question about what statistics we should be
gathering for pages on the Wiki.  (I think I'll be looking at that
sometime this week.)  We we want, on a pages save, which is when we'll be
generating this information, to:

(A) generate a list of links to and from the page.  These will be used, in
	turn, to generate the hub/node lists.  (Globally?  By web?  Both?)
(B) (re)generate the (global?  by web?  both?) index page.  (Which,
	BTW, should be excluded from the hub list!)  Both auto-generations
	will need to use database locks when storing the information/
	generating the page, to prevent simultaneous edits from generating
	bogus indices/lists/etc.  For editing, we may wish to allow
	simultaneity, but iff the last edit 'wins' without side-effects.
(C) check for orphan status.  For the page itself, it can be done fairly
	cheaply, by look-ups in the linked-to lists.  Entries in the
	(global) orphan list (topic: [orphans] or [orphans-in-web]?) can
	be removed if present in this page's linked-to list.  (In general,
	we could arrange special handling for [topics], including limiting
	editing rights to admins and/or disallowing edits for generated
	pages entirely.)
(D) what else?

> How about we color code the "Now Browsing" and/or "Edit 
> <<topic>>" bars for each web.  So the web is indicated by the 
> color code, and is also indicated in the browsing bar.

	OK.  There are two ways of handling this.  The first is to include
per-web variables in the generation of the browse bar, that is, in
CommonHeader.ihtml.  Currently, CommonHeader does /not/ include any
database access code, which I think is a Good Thing.  The second approach
(that /I/ can think of, anyway) is move the browsing bar out of the
CommonHeader, which has the advantage of removing the PHP code from
CommonHeader.  That means that each page would generate the browsing bar
on its own, which would allow things like merging the 'now editing' bar up
into the 'now browsing' bar in edit.php3.  Standardized browser bars could
be assured by moving the CommonHeader stuff into browse.inc, e.g. writing
a function printBrowseBar( $links [, $color] ).

	In general, I try/tried to make the design as generic as possible
so that we could do things like this.  The decision to allow PHP in the
per-web header/footers, for instance, allows a change like this to occur.  
Basically, what each sfWiki site must decide is how much of each page is
going to be exactly the same, or similar, and how much code/db access they
want to go on before any part of the page is sent to the browser.  (My
feeling is that you want a fairly good framework pushed out so your error
messages will look more professional, and to start the downloading as
early as possibly for narrow netlinks.  If db lookups/php code starts
taking noticeable time due to load, pushing the page in chunks, where the
first chunk (not necessarily isomorphic to the first .ihtml file) has no
code or db lookup, and (perhaops) the next chunks have no db lookup, only
php code, will increase effective d/l speed.)

> The page summary information doesn't need to be displayed for the 
> page, you have the full page right there for reading.  The summary 
> should be used for the auto-generated index, and "link to/from" lists 
> to provide additional info about a page.

	Honestly, the summary was just handy as something to test the
code-in-per-web-formatting stuff.  I think it's kind of nice, but I don't
have a good reason for it.  :)

> Finally, the page name itself should be displayed (with the web 
> perhaps) in the "title" are of the page (center of top between the 
> sourceforge logo and topic box).

	Definitely a better use of space.  This could be done in the
CommonHeader stuff, also, because topic should always be defined for page
views.  (If it's not, then CommonHeader can define a default.)  The title
of the whole HTML page would be nice to set, also, even though it would
grossly violate my idea for incremental downloading (w.r.t. no PHP code,
though db stuff would still apply), and could be done the same way.  This
would make bookmarking easier.  (One of the reasons I try to have web and
topic in the URL instead of posted.)

> On normal sfwiki's, the sourceforge logo will be where the project
> logo goes, and the sourceforge logo (and other sponsor logos) will go
> at the bottom of the page or next to the project logo.

	Right.  Actually, if we could dig up a 'wiki' logo, I'd be happy
to put it up with the SF logo, or combine the two.  (Hosted sites are
supposed to have that/the/a logo displayed, though I'm not sure if it's on
every page or what the exact linkage is.  I'll have to look that up.)
 
> That frees about half an inch of screen real estate with no real 
> information loss.  What do you think?

	Sounds good.  I don't think it will overly detract from the look
of the place as an official SourceForge design, either :)

-_Quinn