Subject: Re: Todo for 'portal', programmers perspective

From: Alexey Borzov <[email-masked]>
Date: Thu, 15 Jan 2004 19:58:39 +0300

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.

---

From: Alexey Borzov <[email-masked]>
Date: Thu, 15 Jan 2004 20:30:33 +0300

Hi!

Dave Page wrote:
> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 16 Jan 2004 00:01:17 +0100

> requests such that xxx.html becomes template.php?file=xxx.html or

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.

---

From: Jeroen Ruigrok/asmodai <[email-masked]>
Date: Fri, 16 Jan 2004 06:33:28 +0100

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

---

From: Justin Clift <[email-masked]>
Date: Fri, 16 Jan 2004 22:52:04 +0800

Peter Eisentraut wrote:
<snip>
> 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