sfwiki-devel

[sfWiki-devel] integration with SF code?

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

	While I think it would unnecessarily constrain potential users,
what do you think about maintaining/submitting patches to the
SourceForge code, integrating the Wiki more fully into SourceForge?  Any
kind of work in this direction is (probably) a long ways off, but it's
worth thinking about...

-_Quinn

[sfWiki-devel] info.php3

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

	Should saving a WikiTopic* update all pages links-to-me field?  
Pros: the info.php3 page could be pre-rendered.  Cons: it will take a long
time, and probably require some locking to handle contention
properly.  (That is, we could end up in a situation where every other
topic in the database reflects one edit, and the other half a different
edit.)  It will also require additional space in the database.  The
info.php3 could not be pre-rendered; in fact, neither could the
links-to-me field.  (Thought it may be worthwhile to cache the list
anyway, checking for 'expiration'; this would require another field in the
database, however.)

	That being said, the infastructure for links-to-me (requires
links-from-me field) is in place.  (Though the 'elegant' solution I came
up with for it involves the 'tag' <wikitopic TopicName /wikitopic>!  I
chose not to remove the tags from the final rendered version, in case they
become handy later on :))  This, in turn, means that it will be easy to
determine orphan status, and hub/node lists.**  Furthermore, because the
pre-rendering code includes auto-timestamping, the most-recently-changed
list ought to be fairly simple to generate.

-_Quinn

*: It would be interesting to write a WikiFormatter for emails :) **:
Which brings up the question of generating the global information page.  
I think once-a-day (e.g. by cron) or from the admin pages on-demand is a
good way to go about it; on-the-fly generation will be rather expensive,
and there's probably not a good way to pre-render/cache it -- every edit
would have update things, which would get messy.

Re: [sfWiki-devel] Sunday, May 14 code drop

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

> *whew*  Sounds like a lot of last minute stuff.  It really looks good 
> though.  I look forward to seeing the code drop.

	Well, the first two were really easy.  (I was checking the header
date twice because of a bad cut-and-paste job.)  The third I think I'll
just sit on for now, and add a warning to the script that says make sure
things are how they should be.  The logic for doing table ALTERs could be
extremely painful.

	I actually have one more thing to test before doing the code drop,
and that's if non-root installs will still work.

-_Quinn

Re: [sfWiki-devel] Sunday, May 14 code drop

[Iain S. <iai...@ya...>]

On 13 May 00, at 2:09, Todd L. Miller wrote:

> > However, it is lacking ?all? wiki markup rendering...  I think you 
> > should put a temporary warning in the edit form (where you have 
> 
> 	Done.  Let me know if there's a better way to word it.

Looks good.

> > I'd also add a "cancel" button on the edit page that redirects to the 
> 
> 	I think I'll sit on it, for now.  The most pressing thing before

Sounds good.

> release is to run up and admin page with the edit links for the
> [format-*-*] stuff, because the view.php3 doesn't work too well on them
> anymore :)  Three other quickies -- add a <<phpcgi>> constant to the
> admin.php3 script and edit.inc (how the pre-rendering is done); figure out
> why the footer changing doesn't seem to generate a re-render; and look
> into ALTERing tables that we're told to store into but aren't the right
> type (e.g. old sfWiki installs).

*whew*  Sounds like a lot of last minute stuff.  It really looks good 
though.  I look forward to seeing the code drop.

-iain

Re: [sfWiki-devel] Sunday, May 14 code drop

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

> Yes. works great. And the auto linking is great.  As a first code 
> drop it looks fantastic.  I'd clean up the code (if needed), put your 
> license notices where appropriate, and drop it!

	I will definitely do this before I lose my high-speed netlink this
Sunday.  (Won't get it back for another two or three weeks.)

> However, it is lacking ?all? wiki markup rendering...  I think you 
> should put a temporary warning in the edit form (where you have 
> "editing topicname") that says that wiki markups except WikiName 
> autolinking is not implemented yet... wiki savvy users will do edits 
> and think its broken.

	Done.  Let me know if there's a better way to word it.

> I also notice the edit page drops the common header/footer stuff.  
> Is that intentional?

	*cough*  Of course.  I never make stupid coding errors! :) 

> I'd also add a "cancel" button on the edit page that redirects to the 
> page view for that page without edits.  (we can use the action later 
> to drop page locks if we ever do page locking... currently we 
> (JOSWiki) just leave the locks dangling and rely on lock timeouts 
> which seems like a sad solution).  Perhaps this is a feature 
> request that should wait until after the code drop...

	I think I'll sit on it, for now.  The most pressing thing before
release is to run up and admin page with the edit links for the
[format-*-*] stuff, because the view.php3 doesn't work too well on them
anymore :)  Three other quickies -- add a <<phpcgi>> constant to the
admin.php3 script and edit.inc (how the pre-rendering is done); figure out
why the footer changing doesn't seem to generate a re-render; and look
into ALTERing tables that we're told to store into but aren't the right
type (e.g. old sfWiki installs).
 
> It's your form for the "goto" box. Move your <form> tags outside the 
> table tag for the header table.  forms always get an extra "border" 
> around them which is giving you the extra space...

	Okay, thanks, I fixed this.  Looks much better now.  Also
discovered that headers do wacky things to the baseline, so I moved to
bold +2 font, and got better vertical alignment.

-_Quinn

Re: [sfWiki-devel] Sunday, May 14 code drop

[Iain S. <iai...@ya...>]

On 12 May 00, at 15:49, Todd L. Miller wrote:

> 	OTOH, the pre-rendering stuff is all done and is working

Yes. works great. And the auto linking is great.  As a first code 
drop it looks fantastic.  I'd clean up the code (if needed), put your 
license notices where appropriate, and drop it!

However, it is lacking ?all? wiki markup rendering...  I think you 
should put a temporary warning in the edit form (where you have 
"editing topicname") that says that wiki markups except WikiName 
autolinking is not implemented yet... wiki savvy users will do edits 
and think its broken.

I also notice the edit page drops the common header/footer stuff.  
Is that intentional?

I'd also add a "cancel" button on the edit page that redirects to the 
page view for that page without edits.  (we can use the action later 
to drop page locks if we ever do page locking... currently we 
(JOSWiki) just leave the locks dangling and rely on lock timeouts 
which seems like a sad solution).  Perhaps this is a feature 
request that should wait until after the code drop...

> well.  The one thing I'm wondering about, having removed the sourceforge
> logo from the top in hopes of replacing it with an sfWiki logo, is why
> that particular block is so tall.  If you have any ideas let me know.

It's your form for the "goto" box. Move your <form> tags outside the 
table tag for the header table.  forms always get an extra "border" 
around them which is giving you the extra space...

-iain

[sfWiki-devel] Sunday, May 14 code drop

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

	I want to make the first code drop this Sunday, May 14.  Please
go bash on the wiki at sfwiki.sourcefore.net, which is running the latest
and greatest sfWiki code.  (rev 6, internally, if you're wondering
:))  I'm aware that editing the [format-*-*] topics requires some by-hand
URL editing, but I'm not sure what to do with that yet, and we probably
don't want random strangers futzing with that bit of it anyway.  (And yes,
that means I don't have user auth ready yet.)

	OTOH, the pre-rendering stuff is all done and is working
well.  The one thing I'm wondering about, having removed the sourceforge
logo from the top in hopes of replacing it with an sfWiki logo, is why
that particular block is so tall.  If you have any ideas let me know.

-_Quinn

Re: [sfWiki-devel] web formatting

[Iain S. <iai...@ya...>]

On 10 May 00, at 18:26, Todd L. Miller wrote:

> 	For caching, I'll write a function checkExpired() which will, for
> now, probably use MySQL's date fields.  This has the advantage of
> providing the 'last modified' field for other uses elsewhere for
> nothing.  (Or cache flag or nothing, either way.)

Sounds great.

-iain

Re: [sfWiki-devel] web formatting

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

> I like this option.  We can probably pre-render everything, but leave 
> it open for people to include dynamic stuff if they want.

	OK.  I'll code things like that.

	For caching, I'll write a function checkExpired() which will, for
now, probably use MySQL's date fields.  This has the advantage of
providing the 'last modified' field for other uses elsewhere for
nothing.  (Or cache flag or nothing, either way.)

	I will investage the SF doc pages about their links shortly, and
take the actions we've discussed.

-_Quinn

Re: [sfWiki-devel] web formatting

[Iain S. <iai...@ya...>]

On 9 May 00, at 19:26, Todd L. Miller wrote:

> 	Here's what's up with templates and the speed stuff.  sfWiki,
> right now, only pre-renders the raw text that the user supplied in the
> edit box for that page.  That means that any PHP code executed in the
...
> 	(* e.g.: still use CommonHeader & Footer, but empty, with all the
> stuff done in template.ihtml.)

I like this option.  We can probably pre-render everything, but leave 
it open for people to include dynamic stuff if they want.

> 	I think when we change the template, we can just lock the database
> and NULL out the rendertext column, though I'll have to look into what the
> most efficient way to do this is.  Doing things this way would save a
> 'status' flag.

A status flag is probably more efficient (speed wise).  I don't think 
the memory requirements are going to be a big deal... 1500 pages 
in a directory is big, 1500 records in a database in microscopic!

How about this idea though, we actually just store last rendered 
time for each page.  And an overall, last template change time.  
Then each page that gets drawn out, has a check if the last 
template time (or any other re-render condition) is newer than the 
last rendered time for the page, if so, then re-render.  I guess the 
trade off is the time taken to do these checks at run time versus 
the frequency of global changes that affect all pages such as 
template changes...  

I'm going to waffle back and say that your method of just using a 
status flag (or nuking the pre-rendered page for every page in the 
database) is probably best as I can't see a site changing its 
templates and other sitewide changes that often... if its too often, 
they'll probably move the changes into dynamic page content, ala 
CommonHeader.ihtml.

Of course, because this is such a hard engineering choice 
(tradeoffs galore), the long term best solution is to make the choice 
as modular as possible (functionality via a function call, function 
stored in an included file) so that other wiki deployments can easily 
modify the behavior for their particular application.

> > [JOS] PageName : WebName
> 
> 	One one hand, this isn't in any normal order w.r.t. to
> speficity; on the other, it's probably the best way to order things,
> especially as the WebName isn't particularly important -- since all webs
> are equal to the search engine/topic linker.

Yes.  Plus, with long page names, the web can sometimes not 
show up in normal browser "goto" bookmark lists.  Which is 
preferrable to having the web name be long and the entire list of 
bookmarks look identical because you can't see the page names 
(something that was happening to one of our jos members who 
suggested this format).

> > That would be cool to get a wiki logo.  You are supposed to post a 
> > sourceforge logo on at least your "home page" for your website.  
> > Although sourceforge ranks websites by how many page views 
> > they get from their logo so it may be nice to put the sourceforge 
> > logo on every page.
> 
> 	Right.  Does it have to be a particular logo or will the default
> one that comes with the page work?  (Do you know?)

The specifics are listed on the sourceforge documentation pages.  
Basically, they have a special link (a href around an img tag) that 
they want you to use which will increment their logo view counters 
and credit your sourceforge project.  I'm pretty darn sure that there 
is a specific logo that is sucked in and you don't really have much 
control over what the logo looks like (don't worry it looks cool and 
is small).  It's smaller than the logo you have on 
sfwiki.sourceforge.net.  Check out the documentation pages for 
how to link to it.

-iain

Re: [sfWiki-devel] web formatting

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

> Both.  On the main page we may want a short summary, and on 
> separate pages, a full global and by web listing.

	Of course.  With the include/variable idea, this becomes simpler.

	Here's what's up with templates and the speed stuff.  sfWiki,
right now, only pre-renders the raw text that the user supplied in the
edit box for that page.  That means that any PHP code executed in the
framework/templates is executed on every page view -- which is why I had
concerns about it.  The question is one of balance; how much content is
truly dynamic and how much can we pre-render -- and how much can we
pre-render but code more elegantly as dynamic element?  Off-hand, I can't
think of anything we're doing that can't be cached, but I don't
particularly want to force others into that design without thinking it
through first.  It would possible, in the interim, to do /more/
pre-rendering* but not completely obliterate the possibility for dynamic
stuff. 

	(* e.g.: still use CommonHeader & Footer, but empty, with all the
stuff done in template.ihtml.)

	I think when we change the template, we can just lock the database
and NULL out the rendertext column, though I'll have to look into what the
most efficient way to do this is.  Doing things this way would save a
'status' flag.


> [JOS] PageName : WebName

	One one hand, this isn't in any normal order w.r.t. to
speficity; on the other, it's probably the best way to order things,
especially as the WebName isn't particularly important -- since all webs
are equal to the search engine/topic linker.

> That would be cool to get a wiki logo.  You are supposed to post a 
> sourceforge logo on at least your "home page" for your website.  
> Although sourceforge ranks websites by how many page views 
> they get from their logo so it may be nice to put the sourceforge 
> logo on every page.

	Right.  Does it have to be a particular logo or will the default
one that comes with the page work?  (Do you know?)

-_Quinn

Re: [sfWiki-devel] sf wiki as entire site

[Iain S. <iai...@ya...>]

On 9 May 00, at 16:47, Todd L. Miller wrote:

> > Right now the sfwiki is setup as a subdirectory of the normal 
> > sourceforge website.  This seems to imply its just one part of an 
> > overall website.  Would it be more appropriate to set it up as the 
> > primary and essentially entire website for a sourceforge project?
> 
> 	Yes.  Is it ready yet?*  (The code is set up to expect things in a
> wiki subdirectory.  I'll look into making this change in a portable (e.g.
> for wiki-root and non-wiki-root sites) way in sfWiki-devel as I prepare
> the first code drop.  (Which is, BTW, very nearly done!))  If it is, I'll
> just make the appropriate moves and dump the current index.php3 body into
> the WebHome default topic.

Sounds good.  I think the sfWiki should assume it is THE ENTIRE 
SITE  but play nice if its setup in a subdir of a bigger site.

Glad to hear the code is almost ready for a first drop.  Is session 
management and user logins going to be implemented before the 
drop or is this first version going to be an "unsecured" wiki like c2?

> * That is, (a) do we want to go ahead and do this before the formatting
> changes we've discussed and (b) do we want to go ahead and do this before
> we have version control / user tracking?

IMHO:

I'd make the "wiki as entire site" change first.

Second, do the formatting changes.

Third, do a code drop.  Let the world see and play.  Fix problems 
that crop up.

Fourth, get version control, sessions, login/security and user 
tracking working.

-iain

Re: [sfWiki-devel] sf wiki as entire site

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

> Right now the sfwiki is setup as a subdirectory of the normal 
> sourceforge website.  This seems to imply its just one part of an 
> overall website.  Would it be more appropriate to set it up as the 
> primary and essentially entire website for a sourceforge project?

	Yes.  Is it ready yet?*  (The code is set up to expect things in a
wiki subdirectory.  I'll look into making this change in a portable (e.g.
for wiki-root and non-wiki-root sites) way in sfWiki-devel as I prepare
the first code drop.  (Which is, BTW, very nearly done!))  If it is, I'll
just make the appropriate moves and dump the current index.php3 body into
the WebHome default topic.

-_Quinn

* That is, (a) do we want to go ahead and do this before the formatting
changes we've discussed and (b) do we want to go ahead and do this before
we have version control / user tracking?

[sfWiki-devel] sf wiki as entire site

[Iain S. <iai...@ya...>]

Hello,

Right now the sfwiki is setup as a subdirectory of the normal 
sourceforge website.  This seems to imply its just one part of an 
overall website.  Would it be more appropriate to set it up as the 
primary and essentially entire website for a sourceforge project?

-iain

Re: [sfWiki-devel] Activity on home page

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

> I didn't intend to put stats on every page.  Every page has a 
> "mirror-ing" info page that has stats for that page (revisions, links 
> to, links from, is orphaned, etc).

	Right, OK, the slashbox reference confused me -- because those are
on every page, IIRC.

> But the overall wiki stats should only go on the "default" or "home"
> page for the wiki.  In our case, this is the wiki page with the topic
> WebHome or by going to the wiki with no topic (its the default).  
> Essentially this is the index.php3 for that directory but it should
> also have a valid wiki name so that you can auto link to it easily.  
> We already use the WebHome page for this purpose and I don't see why
> this should change.

	Right.  This neatly solves the problem of where to put per-web
information, too -- <Web>WebHome pages are the defaults for the web, where
the topic WebHome in Main is the default for everyone.  I like the idea of
special tags, BTW.  Esp. if we have people generating their own Wiki 'home
pages' -- e.g. where they jump to after logging in -- special tags would
be a good idea.

-_Quinn

Re: [sfWiki-devel] web formatting

[Iain S. <iai...@ya...>]

On 8 May 00, at 23:39, Todd L. Miller wrote:

> (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?)

Both.  On the main page we may want a short summary, and on 
separate pages, a full global and by web listing.

> (B) (re)generate the (global?  by web?  both?) index page.  (Which,

We should just have certain special pages be auto-generated.  
Then update them when there are changes to the wiki (or 
periodically via a cron job).  A special set of tags would allow us to 
insert certain stats into the page while still editing the page as a 
normal wiki page.

> (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.)

Yes.

> (D) what else?

Total # of pages in the wiki, total # of registered users. # users 
logged in, page edits, total page views, or pages added in last 
day/week/month/year. Complete wiki topic index, total # of 
interwiki links, keyword index (where wiki topic names appear ... 
list by wiki topic, and after it, the pages it appears in).  I'm sure we 
can come up with more but this is a pretty good list.

> > 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] ).

I like the second approach.  How about having a printBrowseLinks() 
that just spews out the text
"<a href="link">WebHome</a> -> <a href="link">Web</a> -> ..."
on a per web basis.  We edit a web_layout_header wiki page that 
we can use to format the look and feel for the that web.  That would 
be adding the actual table row, putting in the Now Browsing: <?php 
printBrowseLinks(); ?> stuff.  This would follow the template style 
used by the TWiki.  (A special %body% tag is used to indicate 
where the wiki body text gets pulled into the template).

> 	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.)

I agree about making this generic.  For the first release, it may be 
best to keep this as simple as possible to avoid sources of errors 
(probably should just ignore my earlier suggestion).  As far as 
download times, aren't we pre-rendering all the pages as they are 
added/edited?  If so, then download times shouldn't be affected by 
the framework or how we structure the php code.  For normal 
downloads its practically instantaneous as all we do is suck the 
pre-rendered page out of the database (on a persistent connection) 
or off the filesystem and spit it at the browser.

Obviously changing the page templates and web outline will require 
every page in the wiki to be regenerated.... but if you think of the 
pre-rendered pages as being in a cache then if something that 
affects the page occurs, it shouldn't be re-rendered until its first 
called for viewing... which basically means, the first time its viewed, 
it will be pre-rendered and "cached".  every subsequent view is 
instantaneous.  And considering the current wiki renders each 
page everytime its view, this is going to be tons more efficient 
albiet more complicated.

> > 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

good.

> title
> of the whole HTML page would be nice to set, also, even though it would

yes.  It should be set in the pre-rendered page.  The format of the 
page titles used by the jos wiki has served us pretty well:

[JOS] PageName : WebName

> > 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 would be cool to get a wiki logo.  You are supposed to post a 
sourceforge logo on at least your "home page" for your website.  
Although sourceforge ranks websites by how many page views 
they get from their logo so it may be nice to put the sourceforge 
logo on every page.

-iain

Re: [sfWiki-devel] Activity on home page

[Iain S. <iai...@ya...>]

On 8 May 00, at 23:04, Todd L. Miller wrote:

> > Any thoughts/comments on a feature like this?
> 
> 	Why not put it on the currently unused wiki/index.php3 page,
> instead of using space on every page in the wiki?  When you're actually
> using the wiki, it's really easy to jump (browse bar) back there, and
> (presumably) you've already found what you're looking for.  Furthermore,
> it shouldn't cover only new pages, but page edits, though we may want to
> do that on a per-web basis.

I didn't intend to put stats on every page.  Every page has a 
"mirror-ing" info page that has stats for that page (revisions, links 
to, links from, is orphaned, etc).  But the overall wiki stats should 
only go on the "default" or "home" page for the wiki.  In our case, 
this is the wiki page with the topic WebHome or by going to the 
wiki with no topic (its the default).   Essentially this is the 
index.php3 for that directory but it should also have a valid wiki 
name so that you can auto link to it easily.  We already use the 
WebHome page for this purpose and I don't see why this should 
change.

And the wiki stats itself should include page edits and new pages 
(but in separate little info boxes sorta like how sourceforge's main 
page shows new projects, and "hot" projects).  In addition, I was 
thinking the total number of wiki members, the total number of wiki 
pages, and other info might be really neat to auto include in the 
WebHome page...  Obviously, we'll need to either make WebHome 
auto generated and not editable, or have special tags for each of 
these stat boxes so they can be auto-rendered and laid out using 
normal wiki editing (i would prefer the second option as its more 
flexible).

-iain

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

Re: [sfWiki-devel] Activity on home page

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

> Any thoughts/comments on a feature like this?

	Why not put it on the currently unused wiki/index.php3 page,
instead of using space on every page in the wiki?  When you're actually
using the wiki, it's really easy to jump (browse bar) back there, and
(presumably) you've already found what you're looking for.  Furthermore,
it shouldn't cover only new pages, but page edits, though we may want to
do that on a per-web basis.

-_Quinn

Re: [sfWiki-devel] Re: new look for sfWiki

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

>  Since this is going to be a "protected" admin only 
> feature, should we make an admin "home page" with normal 
> choices for the admin to make via the web interface.  I can easily 
> see myself forgetting that I can do this via the web (or the format for 
> the page names) if its not put into a "list of admin actions".

	Right.  Makes sense.

> That's easy.  I can provide a zip or tar-gzip of all our files when you 
> want to test it out... of course, we may want to test on a smaller 
> number of pages... :)

	I had completely forgotten about that.  Makes things much easier
:)  (I was trying to think of ways to suck pages across the web...)

> I think the most difficult task is handling 
> "contention" with a page already in the wiki...  I'd probably just 
> ignore it and allow the overwrite... the older version will be available 
> for checking (perhaps it should be flagged though so we can see 
> how many overlaps there are and what pages should be reviewed... 
> a simple, static web page with links to the pages would be 
> sufficient and easy to generat).

	Sounds like a good plan to me.

-_Quinn

[sfWiki-devel] web formatting

[Iain S. <iai...@ya...>]

Hello,

I was looking at the web look and wondering if we might not change 
the format altogether.  I believe in good web design being 
minimalistic and simple.  Faster loading, and more information per 
page.  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.

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.

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).  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.  

That frees about half an inch of screen real estate with no real 
information loss.  What do you think?

-iain

[sfWiki-devel] Activity on home page

[Iain S. <iai...@ya...>]

Hello,

From discussions on the jos lists, one of the most common 
complaints about the wiki is that people think the information is 
old.  This typically occurs because the introductory pages are 
almost always relatively static with edits occuring "deep" into the 
wiki.

I was starting to kick around ideas of providing something like 
some slashdot-ish summaries of new pages on the wiki (page 
name, summary, and the first x words from the new page).  And 
maybe other quick statistics to show how "active" the wiki is.  Sort 
of like our changes page except in a small box on the home page 
of the wiki.  

Any thoughts/comments on a feature like this?

-iain

Re: [sfWiki-devel] Re: new look for sfWiki

[Iain S. <iai...@ya...>]

On 8 May 00, at 18:02, Todd L. Miller wrote:

> > Looks good.  The web header, and web footer table row (highlighted 
> > in yellow section) needs to have its width set to 100% (right now it 
> > doesn't span the entire page).  Otherwise, looks pretty slick.
> 
> 	Personally, I thought setting them both to 60% looked kind of
> nice, but I'm not much of a web designer.  If you feel like futzing with
> them yourself, [format-<Web>-header] and [format-<Web>-footer] are the
> topics to adjust them.

acht.  I forgot that you have them edited from within the wiki itself.  
(very slick)  Since this is going to be a "protected" admin only 
feature, should we make an admin "home page" with normal 
choices for the admin to make via the web interface.  I can easily 
see myself forgetting that I can do this via the web (or the format for 
the page names) if its not put into a "list of admin actions".

> 	A site import script is a very good idea.  The hard part will
> gettign the raw text to import; once we have that, things are easy,
> because saveWikiTopic() is in a .inc file -- so we just call it on our
> import, and all the rendering and linking, etc, stuff automagically
> happens.

That's easy.  I can provide a zip or tar-gzip of all our files when you 
want to test it out... of course, we may want to test on a smaller 
number of pages... :)  I think the most difficult task is handling 
"contention" with a page already in the wiki...  I'd probably just 
ignore it and allow the overwrite... the older version will be available 
for checking (perhaps it should be flagged though so we can see 
how many overlaps there are and what pages should be reviewed... 
a simple, static web page with links to the pages would be 
sufficient and easy to generat).

-iain

[sfWiki-devel] Re: new look for sfWiki

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

[continued from private correspondence]

> Looks good.  The web header, and web footer table row (highlighted 
> in yellow section) needs to have its width set to 100% (right now it 
> doesn't span the entire page).  Otherwise, looks pretty slick.

	Personally, I thought setting them both to 60% looked kind of
nice, but I'm not much of a web designer.  If you feel like futzing with
them yourself, [format-<Web>-header] and [format-<Web>-footer] are the
topics to adjust them.

> Not that I want to discourage use of perl, but you should be able to 
> run php scripts on the command line as the local user just like a 
> perl script.  you either need to type "php scriptname" or use the 
> #!/usr/bin/php script comment... (the path may not be correct for 
> sourceforge).

	Okay, I thought I had tried and failed to get commandline PHP
working at SF, but I'll try it again.  [pause for ssh]  Nope, they work
just fine.  (#!/usr/local/bin/php)  It's my home install that doesn't have
PHP installed for the command line.  (sigh)

	A site import script is a very good idea.  The hard part will
gettign the raw text to import; once we have that, things are easy,
because saveWikiTopic() is in a .inc file -- so we just call it on our
import, and all the rendering and linking, etc, stuff automagically
happens.

-jQuinn