Re: Todo for 'portal', programmers perspective

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