Re: Todo for 'portal', programmers perspective

Mit freundlichen Grüßen
Andreas Grabmüller

----- Original-Nachricht -----
Von: "Alexey Borzov" <borz_off(at)cs(dot)msu(dot)su>
An: pgsql-www(at)postgresql(dot)org
Datum: Thursday, January 15, 2004 04:33 PM
Betreff: [pgsql-www] Todo for 'portal', programmers perspective

> Greetings!
>
> After having a bit of discussion here and after getting acquainted with
> the source code of the "next generation" postgresql.org in pgweb/portal
> I want to give some ideas of mostly architectural and political nature.
>
> To prevent the questions like "who the f*ck is Alexey": I am a PHP
> programmer, a member of the PEAR[1] community, with several opensource
> packages released[2]. I also have experience programming the sites that
> are more complex than postgresql.org. Unfortunately these are
> Russian-only, so no real use giving links here.
>
> First of all, I'd like to thank Andreas Grabmüller for all the work he
> did on portal module. The code *is* working and that means we only have
> to tweak it a bit and not to write everything from scratch.
>
>
> Now on to tweaking.
>
> What is IMO really needed right now is removing the obstacles and
> bottlenecks of website development. Consider the following examples:
> 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.
>
> 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.
>
> 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.
>
>
> * 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.
>
>
> 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.
>
> * 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.
>
>
>
> 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.
>
> * 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.
>
>
>
> I think to roll out a "new" website, the following should be done:
> 1) Separate HTML from the code.
> 2) Decide upon the translation infrastructure.
> 3) Move all the static pages from "www" into "portal" in the form of
> HTML-only templates.
>
> That's all, the site can be published.
>
> As soon as the people send in translations of static content we can add
> them to the site. As soon as a more robust admin interface is in place,
> people can be given rights to publish news, events and surveys in their
> languages.
>
> As soon as someone can come up with a professional-looking design
> (sorry, Dave) the current one can be easily replaced.
>
>
> [1] http://pear.php.net/
> [2] http://pear.php.net/user/avb
> [3] http://www.docbook.org/
> [4] http://www.php.net/manual/howto/
> [5] http://httpd.apache.org/docs/content-negotiation.html
>
>
> ---------------------------(end of broadcast)---------------------------
> T

--
LetzPlay.de
| Freemail: http://www.letzplay.de/mail
| Forenhosting: http://www.letzplay.de/foren
>From pgsql-www-owner(at)postgresql(dot)org Thu Jan 15 12:04:59 2004
X-Original-To: pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (neptune.hub.org [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP id 7D5F3D1E0D0
for <pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu, 15 Jan 2004 16:04:57 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 05103-07
for <pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Thu, 15 Jan 2004 12:04:26 -0400 (AST)
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85])
by svr1.postgresql.org (Postfix) with ESMTP id 9C18AD1E1D2
for <pgsql-www(at)postgresql(dot)org>; Thu, 15 Jan 2004 12:03:21 -0400 (AST)
Received: from mailgate.vale-housing.co.uk ([80.176.1.146] helo=salem.vale-housing.co.uk)
by anchor-post-35.mail.demon.net with esmtp (Exim 3.35 #1)
id 1Ah9xn-0001q0-0Z; Thu, 15 Jan 2004 16:03:19 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: Re: Todo for 'portal', programmers perspective
Date: Thu, 15 Jan 2004 16:03:19 -0000
Message-ID: <03AF4E498C591348A42FC93DEA9661B8720494(at)mail(dot)vale-housing(dot)co(dot)uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pgsql-www] Todo for 'portal', programmers perspective
Thread-Index: AcPbfHgP+o/Btj2PTsioJ+m6OtK6swAAPzNg
From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Alexey Borzov" <borz_off(at)cs(dot)msu(dot)su>, <pgsql-www(at)postgresql(dot)org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200401/99
X-Sequence-Number: 3338

=20

> -----Original Message-----
> From: Alexey Borzov [mailto:borz_off(at)cs(dot)msu(dot)su]=20
> Sent: 15 January 2004 15:29
> To: pgsql-www(at)postgresql(dot)org
> Subject: [pgsql-www] Todo for 'portal', programmers perspective
>=20
>
> 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=20
> web-interface then there is a bottleneck: the person who=20
> gives access to web-interface. If the interface is not robust=20
> enough to let not-quite-trusted people use it, then the=20
> bottleneck is even more narrow. On the other hand, if the=20
> content is available in public CVS, then every one may check=20
> 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? :-)

>=20
> 2) If some of the critical data --- DB schema, docs, ToDo=20
> lists --- is missing from CVS then the person wishing to=20
> participate in the development will not be able to do this=20
> 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=20
> and even duplicated in several files then the person wishing=20
> to tweak the design or to contribute the completely new one=20
> will be unable to do this. The bottleneck is again the person=20
> 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.
>=20
> * I18n and l10n issues
>=20
> There are separate internationalization tasks:
> 1) Translating the framework itself and static content
>=20
> For the pages that are mostly the same in different languages=20
> and for the PHP scripts themselves gettext extension or=20
> something like this can be used. Current solution with=20
> {LNG_whatever} placeholders is extremely fragile, as all=20
> translations should be updated manually in several places.
>=20
> Text-intensive pages with not much layout must be kept in CVS=20
> in all availbale languages.
>=20
> The benefits of this approach: people wishing to translate=20
> website will be able to checkout the current code and work on=20
> 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.

>=20
> 2) Making it possible to publish dynamic content in several languages
>=20
> This is mostly done, but not actually usable without robust=20
> admin interface.
>=20
> For Dave, on documentation: PostgreSQL documentation is being=20
> done in DocBook[3] this is SGML (or XML) based format that=20
> does not have presentation markup, unlike HTML. It is=20
> converted into other formats via special stylesheets. This is=20
> how PostgreSQL's HTML and PDF docs are being generated. If=20
> there is a need to translate the docs, then DocBook source=20
> should be translated, and there are special tools for this.=20
> You can consult PHP documentation HowTo[4], it is a good=20
> 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.
>=20
> This is quite simple: if someone wants to tweak the website's=20
> layout, he must be able to do this without having to bother=20
> with the actual code.=20
> Thus HTML-only templates (or with *minimal* PHP) are needed.
>=20
> Very few templates will be actually needed: one for the whole=20
> website "frame" and one for each distinct page that is=20
> available now in "www"=20
> 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=3Dxxx.html or
similar?

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

Agreed.

> * Administrative interface
>=20
> There is fair amount of work needed here. There should be builtin=20
> authentication and access control system here, so that people having=20
> 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=20
> 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=20
> (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.