Re: Proposal for building knowledgebase website. - Mailing list pgsql-www

> -----Original Message-----
> From: Gevik Babakhani [mailto:gevik@xs4all.nl]
> Sent: 10 June 2005 12:19
> To: Dave Page; 'Magnus Hagander'; josh@agliodbs.com; 'Marc G.
> Fournier'
> Cc: pgsql-www@postgresql.org
> Subject: RE: [pgsql-www] Proposal for building knowledgebase website.
>
> I think it would be wise if we just installed this thing
> first and play with
> it for a couple of weeks. Create accounts in it and just use
> it as if it was
> in production. Like a proof of concept as suggested in latest
> posts. Just
> then we could really say if the CMS is working for us.

OK - I believe Marc is setting that up.

> To my experience, CMS systems make you design and develop
> your information
> system in a pre-decided and pre-dictated fashion and most of
> the time you
> have to hack your way around to get it look and feel and work
> the way you
> really want, resulting something far off from the original
> requirement.
> This is where I like to remind we should be aware this
> out-of-the-box CMS
> isn't overkill.

I think it probably is, however, if that's what the actual intended
contributors would like, then let them have it as long as it produces
output we can use in the main site. To do so, it needs to produce pages
that look like (not including the two dashed lines):

--------------------------------------------------------

<!-- BEGIN page_title_block -->
About
<!-- END page_title_block -->
<h1>About</h1>

<p>PostgreSQL is an object-relational database management system
(ORDBMS)
based on POSTGRES, Version 4.2, developed at the University of
California
at Berkeley Computer Science Department. POSTGRES pioneered many
concepts
that only became available in some commercial database systems much
later.</p>

<ul>
  <li>Foo</li>
  <li>Baa</li>
<ul>

<p>some <b>bold</b> text</p>

--------------------------------------------------------

The rest of the page can be formatted as required, using the most
simplistic XHTML 1.0 Strict compliant tags - ie. With no inline
css/fonts/colours etc. These pages do not need any menus, headers or
footers etc. as the framework will add these, as well as the appropriate
stylesheets.


> If you think about the real functionality we require, you end
> up with the
> following.
>
> The kb:
>
> - Must integrate into the current system. I don't think we
> want to change
> the current system drastically to fit any CMS. After all from
> what I saw in
> the sources, there is been a lots and lots of work done to get here.


The CMS should produce a bunch of files similar in format to the example
above. A script then runs every hour and checks these files into the
pgweb CVS. From there on, no further work need be done. The live site
/already/ automatically updates and rebuilds itself from CVS every hour,
so getting the template pages into the CVS is all the integration that
is required.

> - Easy to navigate: you must be able to see the picture
> without digging page
> to page to get any information. Have you ever checked this:
>
> http://w4teclipse.com:8765/help/index.jsp?topic=/com.w4t.eclip
> se.developer.h
> elp/html/reference/api/com/w4t/dhtml/package-summary.html
>
> or http://msdn.microsoft.com/library/
> or http://www.cs.washington.edu/dm/vfml/

Yes, now this is where the magic comes in. The CMS should be able to
output some sort of index file along with all the content. This may just
be another simple page with hyperlinks in a hierarchy of <UL></UL> tags,
e.g:

<ul>
  <li>Item 1</li>
  <ul>
    <li>Item 1, subitem 1</li>
    <li>Item 1, subitem 2</li>
  </ul>
  <li>Item 2</li>
</ul>

A new indexing script is then added to the web framework that parses
that file and generates the navigation tree.


> - Easy markup. We could plug in something like "kupu"
> (http://kupu.oscom.org/screenshots/) and filter the edited
> page on some
> unwanted tags.

Yes, that is an option if a CMS is not used.

> - People must be able to easily contribute: we can adopt the
> www.codeproject.com idea. People create account, they
> contribute, if the
> contribution ranks high or it was accepted (it was good to
> keep), then the
> contribution gets a stable status and it is accepted in the
> permanent kb.

Bricolage should handle all of this, however, if we don't use a CMS,
then a simple moderation email to the pgsql-slavestothewww list would
suffice in the same way that we currently moderate doc comments, news
and events etc.

> - must be manageable in the future. And not too much hassle regarding
> administration, mirroring and upgrades.

By keeping the CVS as a buffer between the CMS and the frontend site,
mirroring and upgrades etc, needn't affect the website at all. You could
even replace the CMS with something entirely different, and as long the
replacement wrote it's output in the same place, in the same simple
format, it would make no difference to the website.

> I mean think about this. You can never know what a person knows about
> PostgreSQL. (except for the ones that we know by
> communicating during past
> years) Is he a database user, a pg programmer, a db
> administrator of just
> someone who doesn't like pg and try to fill the kb with
> crappy information.
> How are we going to address these issues with of without an
> out-of-the-box
> CMS.  And of course you wouldn't want our dear future
> contributors write
> wonderful articles about how you do a SELECT * FROM.

Indeed.

> I just hate to see this becoming an uncontrollable monster eventually
> disinterest people using it. I am sure the current techdocs
> that is almost
> dead, was setup with good intentions.

This is another reason why I like the CMS -> CVS -> Web idea. Even if
the CMS dies a death and falls into disuse, all the content will be on
the main website in the appropriate format, and will be subject to all
future style/layout changes, and may be updated just like any other page
on the site.

Regards, Dave.