Re: Todo for 'portal', programmers perspective - Mailing list pgsql-www

> -----Original Message-----
> From: Alexey Borzov [mailto:borz_off@cs.msu.su]
> Sent: 15 January 2004 15:29
> To: pgsql-www@postgresql.org
> Subject: [pgsql-www] Todo for 'portal', programmers perspective
>
>
> 1) If all the static content (i.e. the content that does not change
> often) is stored in the database and is editable only through
> web-interface then there is a bottleneck: the person who
> gives access to web-interface. If the interface is not robust
> enough to let not-quite-trusted people use it, then the
> bottleneck is even more narrow. On the other hand, if the
> content is available in public CVS, then every one may check
> it out and edit it and later submit for inclusion.

The same bottleneck applies either way as those with access to the admin
interface are basically those with cvs commit access. Still, CVS does
give more convenient read-only access than the web does.

However, we should avoid using CVS as a content management system. I
have no experience of it failing myself but istr reports from others
here who have. Can anyone back this up with examples, or am I imagining
it? :-)

>
> 2) If some of the critical data --- DB schema, docs, ToDo
> lists --- is missing from CVS then the person wishing to
> participate in the development will not be able to do this
> without fishing for the appropriate info somewhere.

The DB schema is not in the CVS at present. I'm not convinced it should
be: Developers working elsewhere will need data as well as schema,
however, the data is purposefully not included as it makes the dump a
very large file.

Happy to hear suggestions for handling that little problem...

I have also enabled the task manager on the Gborg project so that ToDo
items may be kept there.

> 3) If site's layout is kept in the spaghetti of PHP and HTML
> and even duplicated in several files then the person wishing
> to tweak the design or to contribute the completely new one
> will be unable to do this. The bottleneck is again the person
> with the knowledge of this spaghetti.

The same applies to a complex multilayer template system. As I have said
previously (albeit in different words), we need to find a happy medium.
>
> * I18n and l10n issues
>
> There are separate internationalization tasks:
> 1) Translating the framework itself and static content
>
> For the pages that are mostly the same in different languages
> and for the PHP scripts themselves gettext extension or
> something like this can be used. Current solution with
> {LNG_whatever} placeholders is extremely fragile, as all
> translations should be updated manually in several places.
>
> Text-intensive pages with not much layout must be kept in CVS
> in all availbale languages.
>
> The benefits of this approach: people wishing to translate
> website will be able to checkout the current code and work on
> the website without having to ask anyone.

This means we have 2 methods of publishing data. How do we decide how to
handle a given file - by the directory it is in, or by individual
assessment.

We need *one* system for this. I'm willing to concede that the docs are
a special case, but we do need to consider static content as well as
news, events, and script processors.

>
> 2) Making it possible to publish dynamic content in several languages
>
> This is mostly done, but not actually usable without robust
> admin interface.
>
> For Dave, on documentation: PostgreSQL documentation is being
> done in DocBook[3] this is SGML (or XML) based format that
> does not have presentation markup, unlike HTML. It is
> converted into other formats via special stylesheets. This is
> how PostgreSQL's HTML and PDF docs are being generated. If
> there is a need to translate the docs, then DocBook source
> should be translated, and there are special tools for this.
> You can consult PHP documentation HowTo[4], it is a good
> introduction for beginners.

Yes, it would make sense to translate the SGML rather than the HTML (now
I understand what you were getting at before). There is currently only a
German translation of the docs produced by Peter Eisentraut, however I
don't know if he translated the SGML (I would be surprised if he
hadn't).

> * Separation of HTML from the actual code.
>
> This is quite simple: if someone wants to tweak the website's
> layout, he must be able to do this without having to bother
> with the actual code.
> Thus HTML-only templates (or with *minimal* PHP) are needed.
>
> Very few templates will be actually needed: one for the whole
> website "frame" and one for each distinct page that is
> available now in "www"
> module, of these some will be language specific.

Do we really need a template for each static page? Can we not rewrite
requests such that xxx.html becomes template.php?file=xxx.html or
similar?

> Now lets move to more technical issues
>
> * Static page generation
>
> This is working now, I suppose. I only want to suggest using
> pagename.lang.html instead of lang/pagename.html to be able to use
> Apache's content negotiation[5] on static website mirrors, as
> suggested
> by Peter Eisentraut.

Agreed.

> * Administrative interface
>
> There is fair amount of work needed here. There should be builtin
> authentication and access control system here, so that people having
> access to e.g. German translation couldn't f*ck up anything else.

If we work mainly from CVS as you advocated earlier, then the web
interface would only be for mirror admin/moderation as it is now - hence
a more robust solution is not a necessity.

> I think to roll out a "new" website, the following should be done:
> 1) Separate HTML from the code.

And fix any minor layout issues with the tweaked, non-fixed width
design.

> 2) Decide upon the translation infrastructure.

Yes.

> 3) Move all the static pages from "www" into "portal" in the form of
> HTML-only templates.

Yes.

> That's all, the site can be published.

Not quite - part of the plan was also to ensure XHTML strict compliance
(Michael?)

Then, that is the 'phase 1' of the plan that I have mentioned earlier
complete.

> As soon as someone can come up with a professional-looking design
> (sorry, Dave) the current one can be easily replaced.

That is phase 2.

Phase 3 is merging/restructuring of www, advocacy and developer (exactly
how to is TBD) into the new structure, and revising/reviewing all
content.

That sounds more like a plan :-)

Regards, Dave.