public inbox for [email protected]
help / color / mirror / Atom feedTodo for 'portal', programmers perspective
12+ messages / 5 participants
[nested] [flat]
* Todo for 'portal', programmers perspective
@ 2004-01-15 15:29 Alexey Borzov <[email protected]>
2004-01-15 16:56 ` Re: Todo for 'portal', programmers perspective Alexey Borzov <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Alexey Borzov @ 2004-01-15 15:29 UTC (permalink / raw)
To: pgsql-www
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
2004-01-15 15:29 Todo for 'portal', programmers perspective Alexey Borzov <[email protected]>
@ 2004-01-15 16:56 ` Alexey Borzov <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Alexey Borzov @ 2004-01-15 16:56 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-www
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 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).
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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-15 16:38 Dave Page <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Dave Page @ 2004-01-15 16:38 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Alexey Borzov <[email protected]>; pgsql-www
> -----Original Message-----
> From: Robert Treat [mailto:[email protected]]
> Sent: 15 January 2004 16:31
> To: Dave Page
> Cc: Alexey Borzov; [email protected]
> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-15 16:58 ` Alexey Borzov <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Alexey Borzov @ 2004-01-15 16:58 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Dave Page <[email protected]>; pgsql-www
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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-15 17:30 ` Alexey Borzov <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Alexey Borzov @ 2004-01-15 17:30 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgsql-www
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-15 23:01 ` Peter Eisentraut <[email protected]>
2004-01-16 05:33 ` Re: Todo for 'portal', programmers perspective Jeroen Ruigrok/asmodai <[email protected]>
2004-01-16 14:52 ` Re: Todo for 'portal', programmers perspective Justin Clift <[email protected]>
2 siblings, 2 replies; 12+ messages in thread
From: Peter Eisentraut @ 2004-01-15 23:01 UTC (permalink / raw)
To: Dave Page <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
2004-01-15 23:01 ` Re: Todo for 'portal', programmers perspective Peter Eisentraut <[email protected]>
@ 2004-01-16 05:33 ` Jeroen Ruigrok/asmodai <[email protected]>
1 sibling, 0 replies; 12+ messages in thread
From: Jeroen Ruigrok/asmodai @ 2004-01-16 05:33 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Dave Page <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
-On [20040116 00:03], Peter Eisentraut ([email protected]) 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...
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
2004-01-15 23:01 ` Re: Todo for 'portal', programmers perspective Peter Eisentraut <[email protected]>
@ 2004-01-16 14:52 ` Justin Clift <[email protected]>
1 sibling, 0 replies; 12+ messages in thread
From: Justin Clift @ 2004-01-16 14:52 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Dave Page <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-15 23:27 Dave Page <[email protected]>
2004-01-16 05:31 ` Re: Todo for 'portal', programmers perspective Jeroen Ruigrok/asmodai <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Dave Page @ 2004-01-15 23:27 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
> -----Original Message-----
> From: Peter Eisentraut [mailto:[email protected]]
> Sent: 15 January 2004 23:01
> To: Dave Page; Alexey Borzov; [email protected]
> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
2004-01-15 23:27 Re: Todo for 'portal', programmers perspective Dave Page <[email protected]>
@ 2004-01-16 05:31 ` Jeroen Ruigrok/asmodai <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Jeroen Ruigrok/asmodai @ 2004-01-16 05:31 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
-On [20040116 00:32], Dave Page ([email protected]) 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...
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
@ 2004-01-16 08:18 Dave Page <[email protected]>
2004-01-16 08:26 ` Re: Todo for 'portal', programmers perspective Jeroen Ruigrok/asmodai <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Dave Page @ 2004-01-16 08:18 UTC (permalink / raw)
To: Jeroen Ruigrok/asmodai <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Alexey Borzov <[email protected]>; pgsql-www
> -----Original Message-----
> From: Jeroen Ruigrok/asmodai [mailto:[email protected]]
> Sent: 16 January 2004 05:33
> To: Peter Eisentraut
> Cc: Dave Page; Alexey Borzov; [email protected]
> Subject: Re: [pgsql-www] Todo for 'portal', programmers perspective
>
> -On [20040116 00:03], Peter Eisentraut ([email protected]) 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Todo for 'portal', programmers perspective
2004-01-16 08:18 Re: Todo for 'portal', programmers perspective Dave Page <[email protected]>
@ 2004-01-16 08:26 ` Jeroen Ruigrok/asmodai <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Jeroen Ruigrok/asmodai @ 2004-01-16 08:26 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Alexey Borzov <[email protected]>; pgsql-www
-On [20040116 09:22], Dave Page ([email protected]) 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...
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2004-01-16 14:52 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-01-15 15:29 Todo for 'portal', programmers perspective Alexey Borzov <[email protected]>
2004-01-15 16:56 ` Alexey Borzov <[email protected]>
2004-01-15 16:38 Re: Todo for 'portal', programmers perspective Dave Page <[email protected]>
2004-01-15 16:58 ` Alexey Borzov <[email protected]>
2004-01-15 17:30 ` Alexey Borzov <[email protected]>
2004-01-15 23:01 ` Peter Eisentraut <[email protected]>
2004-01-16 05:33 ` Jeroen Ruigrok/asmodai <[email protected]>
2004-01-16 14:52 ` Justin Clift <[email protected]>
2004-01-15 23:27 Re: Todo for 'portal', programmers perspective Dave Page <[email protected]>
2004-01-16 05:31 ` Jeroen Ruigrok/asmodai <[email protected]>
2004-01-16 08:18 Re: Todo for 'portal', programmers perspective Dave Page <[email protected]>
2004-01-16 08:26 ` Jeroen Ruigrok/asmodai <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox