Re: Todo for 'portal', programmers perspective - Mailing list pgsql-www

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