Thread: 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
Mit freundlichen Grüßen
Andreas Grabmüller
----- Original-Nachricht -----
Von: "Alexey Borzov" <borz_off@cs.msu.su>
An: pgsql-www@postgresql.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
> -----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.
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
havingdifferent templates for different languages is a good idea as this would destroy all benefits of templates (we
wouldhave 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
surethat every apache installation supports that content negotiation). I think this is what the debian website does,
isn'tit?
Mit freundlichen Grüßen
Andreas Grabmüller
----- Original-Nachricht -----
Von: "Alexey Borzov" <borz_off@cs.msu.su>
An: pgsql-www@postgresql.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@postgresql.org)
--
LetzPlay.de
| Freemail: http://www.letzplay.de/mail
| Forenhosting: http://www.letzplay.de/foren
On Thu, 2004-01-15 at 11:03, Dave Page wrote:
> > -----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.
>
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
> -----Original Message----- > From: Robert Treat [mailto:xzilla@users.sourceforge.net] > Sent: 15 January 2004 16:31 > To: Dave Page > Cc: Alexey Borzov; pgsql-www@postgresql.org > Subject: Re: [pgsql-www] Todo for 'portal', programmers perspective > > > > > 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. 'Tis also difficult without any content to work with. Maybe we should have a link to a nightly dump of the schema only and the schema + data? That way, developers can grab whichever they want. Thoughts? Regards, Dave.
Hi!
Andreas Grabmüller wrote:
> However. I personally like template systems. But how do you want to handle the translations with it? I don't think
havingdifferent templates for different languages is a good idea as this would destroy all benefits of templates (we
wouldhave to manage the same layout multiple times).
The one I originally proposed allows callback functions to be defined.
I.e. instead of
<a href="..."><?php translate('Download'); ?></a>
you write
<a href="...">func_translate(Download)</a>
within a template, this is quite viewable and editable and the string
translations can still be kept in a central place.
Hi! Robert Treat wrote: >>>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. I want to once again point out that this applied to static content, not to news and events which should of course be managed through web interface.
Hi! Dave Page wrote: > 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? :-) CVS should not be a "CMS", that's true. But they should IMO complement each other. >>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... A good idea is to provide some "sample" data for populating the database along with the schema. > I have also enabled the task manager on the Gborg project so that ToDo > items may be kept there. Thanks! >>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. Well, nothing too complex here. Each page will need two template files: a common file for website layout and the one for the page's content. It will be less complex than now, where the common layout is kept in *several* files and page-specific HTML is generated in yet other ones. But I suspect that I won't be able to persuade you here until I show some code using templates. >>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. Well, let's see here. If the content tends to be added/changed a lot (like news, events, articles if we ever do those) then it should be kept in the database and managed through web-interface. Then there are pages that show that dynamic content (main page, news, events, mirrors and such). These will probably need one template for all languages, with gettext() applied. At last, there are pages that have a lot of text, but are static by nature, an example: http://www.postgresql.org/lists.html It is possibly better to have separate templates for each language here, as f.e. German list should be higher on German language version... >>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? Yes, that's exactly how it works now. I am not proposing to change this. :] Let's clarify language: we'll have a template (HTML) for each static page and one script (PHP) that will choose the template to load. >>* 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. How are you going to publish news and events in foreign languages? Especially the ones where you can't understand that the item is displayed correctly. ;] > Not quite - part of the plan was also to ensure XHTML strict compliance > (Michael?) Well, after HTML is separated, this will be a trivial thing to do. > Then, that is the 'phase 1' of the plan that I have mentioned earlier > complete. OK, so a good idea is to actually start phase 1, item 1 (separation of HTML). And also to change urls to pagename.html.lang
Dave Page wrote:
> 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?
Heaven, please no URLs like that.
In fact I would propose, for a future iteration perhaps, to put each
file in a separate directory and name them index.lang.{html,php} and
only publish the directory based URLs. Compare the links at
http://www.debian.org/
http://www.kde.org/
http://www.gnome.org/
All the URLs are very readable and don't expose implementation details.
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: 15 January 2004 23:01 > To: Dave Page; Alexey Borzov; pgsql-www@postgresql.org > Subject: Re: [pgsql-www] Todo for 'portal', programmers perspective > > Dave Page wrote: > > 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? > > Heaven, please no URLs like that. They would be hidden from the user - mod_rewrite converts friendly urls to not so friendly ones on the fly. Regards, Dave.
-On [20040116 00:32], Dave Page (dpage@vale-housing.co.uk) wrote: >They would be hidden from the user - mod_rewrite converts friendly urls >to not so friendly ones on the fly. It does have a history of being security unsafe though. =\ So make sure that people can upgrade/fix stuff quickly in different timezones when it might have a problem. -- Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here...
-On [20040116 00:03], Peter Eisentraut (peter_e@gmx.net) wrote:
>In fact I would propose, for a future iteration perhaps, to put each
>file in a separate directory and name them index.lang.{html,php} and
>only publish the directory based URLs. Compare the links at
For the one configuring the httpd.conf, using Peter's suggestion, make
sure to have:
DirectoryIndex index
since it needs to match: index + .lang + .extension
But yeah, I would agree to Peter's scheme, if only for the fact your
keep the right extension to a file (makes editing with a lot of text
editors way more friendly).
--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://diary.in-nomine.org/
Don't try to find the Answer where there ain't no Question here...
> -----Original Message-----
> From: Jeroen Ruigrok/asmodai [mailto:asmodai@wxs.nl]
> Sent: 16 January 2004 05:33
> To: Peter Eisentraut
> Cc: Dave Page; Alexey Borzov; pgsql-www@postgresql.org
> Subject: Re: [pgsql-www] Todo for 'portal', programmers perspective
>
> -On [20040116 00:03], Peter Eisentraut (peter_e@gmx.net) wrote:
> >In fact I would propose, for a future iteration perhaps, to put each
> >file in a separate directory and name them index.lang.{html,php} and
> >only publish the directory based URLs. Compare the links at
>
> For the one configuring the httpd.conf, using Peter's
> suggestion, make sure to have:
>
> DirectoryIndex index
>
> since it needs to match: index + .lang + .extension
Hmm, that will cause pain. Currently we rely on the line:
DirectoryIndex index.html index.php
The extensions (and their order) are part of the way the whole system
works.
Regards, Dave.
-On [20040116 09:22], Dave Page (dpage@vale-housing.co.uk) wrote: >Hmm, that will cause pain. Currently we rely on the line: > >DirectoryIndex index.html index.php > >The extensions (and their order) are part of the way the whole system >works. Then you'd need to go the file.html.lang route. -- Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here...
Peter Eisentraut wrote: <snip> > http://www.debian.org/ > http://www.kde.org/ > http://www.gnome.org/ Or: http://advocacy.postgresql.org Same principle there. Slightly different handling of the language aspect, but what Peter's talking about is how the Advocacy site works. > All the URLs are very readable and don't expose implementation details. Yep. Regards and best wishes, Justin Clift