Re: Todo for 'portal', programmers perspective

Erm, where has my text gone?

However. I personally like template systems. But how do you want to handle the translations with it? I don't think having different templates for different languages is a good idea as this would destroy all benefits of templates (we would have to manage the same layout multiple times).

Creating the static pages as pagename.html.lang is a good idea if we can be sure all mirrors use apache (and if we are sure that every apache installation supports that content negotiation). I think this is what the debian website does, isn't it?

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)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
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:32:12 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 B8156D1D8AE
for <pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu, 15 Jan 2004 16:32:10 +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 09880-08
for <pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Thu, 15 Jan 2004 12:31:38 -0400 (AST)
Received: from bramble.mmrd.com (unknown [65.217.53.66])
by svr1.postgresql.org (Postfix) with ESMTP id F373DD1B458
for <pgsql-www(at)postgresql(dot)org>; Thu, 15 Jan 2004 12:31:36 -0400 (AST)
Received: from thorn.mmrd.com (thorn.mmrd.com [172.25.10.100])
by bramble.mmrd.com (8.12.8/8.12.8) with ESMTP id i0FFp0cM024163;
Thu, 15 Jan 2004 10:51:01 -0500
Received: from gnvex001.mmrd.com (gnvex001.mmrd.com [192.168.3.55])
by thorn.mmrd.com (8.11.6/8.11.6) with ESMTP id i0FGUsl25849;
Thu, 15 Jan 2004 11:30:57 -0500
Received: from camel.mmrd.com ([172.25.5.213]) by gnvex001.mmrd.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
id XT88ADQZ; Thu, 15 Jan 2004 11:30:52 -0500
Subject: Re: Todo for 'portal', programmers perspective
From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Alexey Borzov <borz_off(at)cs(dot)msu(dot)su>, pgsql-www(at)postgresql(dot)org
In-Reply-To:
<03AF4E498C591348A42FC93DEA9661B8720494(at)mail(dot)vale-housing(dot)co(dot)uk>
References: <03AF4E498C591348A42FC93DEA9661B8720494(at)mail(dot)vale-housing(dot)co(dot)uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8
Date: 15 Jan 2004 11:30:54 -0500
Message-Id: <1074184254(dot)17856(dot)416(dot)camel(at)camel>
Mime-Version: 1.0
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200401/101
X-Sequence-Number: 3340

On Thu, 2004-01-15 at 11:03, Dave Page wrote:
> > -----Original Message-----
> > From: Alexey Borzov [mailto:borz_off(at)cs(dot)msu(dot)su]
> > Sent: 15 January 2004 15:29
> > To: pgsql-www(at)postgresql(dot)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.
>

I'd like to point out that from a management standpoint, I think we've
been fairly responsive when it comes to news & events, so I don't see a
bottleneck there. On top of that, ISTM that it is easier to for end
users to submit news and to get it approved if its in a web/db based
system.

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

Josh is the champion of this, mainly because he doesn't like to code and
wanted to contribute content and found bottlenecks when Justin was
running techdocs. Personally I think techdocs could be run completely
via CVS if there were a few people willing to code up article
submissions. I think in whatever technology you choose, the maxim that
users shouldn't be forced to use CVS to submit new content is true.

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

ISTM development no on the server is orders of magnitude harder without
having a database available to hit against.

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

ISTM that adding a few layout functions in php that are called from
within the various pages would suffice. Thats how its done on the
php.net pages...

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

I think this could be step 1.5, though probably doesnt hurt to do it all
at once.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL