[imc-sf-active] static sites with smarty

[gekked at blackflag.net]

Hey all, please take a look at:
http://sfa.indymedia.org/news/2004/12/70.php

I wrote up a summary of sf-active concepts so we can have a
grounding in what we're talking about towards a 1.0 release.

The major concepts we're tackling towards that are: templating,
admin content management, mirroring/caching and the normal stuff
of cleaning up the codebase and having a coherent code design.

Right now, I'm debugging the webcast table changes I recently
committed which make the open publishing part of stuff more
object-oriented with a db separation of articles & comments.
After that, I'd like to begin adding in the SF code without
branching -- reason being that it is separated enough that
there isn't a clear reason to branch. The other major thing
going on right now is Bart's work doing the conversion to
Smarty and the proposed makeover of the Admin Interface (which
I'm all in favor of).

Given that, here's my comments on Bart's email:

> date/time presentation.
>     - in the page_handler script, we do setlocale('LC_TIME') per
>       $language, then smarty's date_format can handle the output.
>     (this is a big ++ since, we don't really need code to do it :-)

excellent..

> ** Producer stuff **
> local/includes
>     - i've created templates for the includes. it's quite basic, but it
[...]
> sitename/static
>     - we create per language (and if it's configured also $lang.'mix'
>       directories were static sites go. 
>     - mix is for presentation of a site in language $x but with content

This part I'm not sure about. It would be nice to have includes and other
filesystem-dependent stuff become obsolete (which is doable with Page-Based
Editing). But, I don't really understand it and haven't looked too much 
at the new code. Ultimately, we do need some master script which could be
called the Producer that you can basically run and have it generate an 
entire site based on what it finds in the database. With the SF admin 
code, we're just about there with doing that. It works fundamentally just
like Mir, except their page definitions are accessible via XML and our
page definitions are accessible through SQL.


> * static-site concept *
>     - the idea isn't really to do dynamic-master and static mirrors, but a
>       concept with 3 parts:
> 	- 1 master site were dbase writes happens and producing takes
> 	  place. (this is like the site we have now).
> 	- ev. multiple dynamic sites. for this we need:
> 	    - a replicated dbase.
> 	    - an sf-active install.
> 	    (here we do dbase reads for search..)
> 	    (note: such a dyn. site doesn't have to be a mirror, the
> 	    search can link to static mirrors
> 	- static mirrors. just php files which do include('');
> 	(actually, static mirrors can be 2 types:
> 	    - php-files
> 	    - media files.

This part I agree with and I included it in the Overview document I wrote.
-gek