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