Skip site navigation (1) Skip section navigation (2)

Re: Todo for 'portal', programmers perspective

From: "Andreas Grabmller" <webmaster(at)letzplay(dot)de>
To: pgsql-www(at)postgresql(dot)org, borz_off(at)cs(dot)msu(dot)su
Subject: Re: Todo for 'portal', programmers perspective
Date: 2004-01-15 16:24:25
Message-ID: 20040115162425.8670.qmail@osiris.gamecrashnet.de (view raw or flat)
Thread:
Lists: pgsql-www
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


In response to

Responses

pgsql-www by date

Next:From: Dave PageDate: 2004-01-15 16:38:40
Subject: Re: Todo for 'portal', programmers perspective
Previous:From: Andreas GrabmllerDate: 2004-01-15 15:50:22
Subject: Re: Todo for 'portal', programmers perspective

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group