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

Ok. I got in late on this one as I wasn't in last night. Here are a
bunch of different comments.


Josh:
> > Without the ability to publish static HTML files (which
> Gavin states
> > Framewerk can't do), I don't think that it will be the
> right direction
> > for this ...
>
> Static HTML is only an issue if we expect it to need
> mirroring.  Which the old Techdocs never did.

Right. Which is one reason it was very good that Google Cache existed,
so you could actually *get* to the articles in a speedy manner :(
The old techdocs was often slow and often down. It's a lot better these
days (yeah, I know, it's still the old techdocs, but let's say just
"back in the days" then), but still. There has been a lot invested in
buildign the balancing/failover system for the main website, and we'd be
fools not to use that.


Marc:
> 'k, since it looks like we're "agreed" here on what needs to
> happen, I'm going to setup a bricolage.postgresql.org VM
> (again) so that we can get started ... I'll need to do some
> upgrades to the latest version of Bricolage, but taht won't
> take too long ...

Um. Shouldn't we first determine that we *know* that this is a good way
of doing it? Meaning at least a proof-of-concept of the "bric can
generate what's needed to fully integrate with the current site"?



I for one am not fully "agreed" *yet*. Again, if bric can fullfill our
requirements, then hell yes, I'm in. But there are several points I
don't see adressed yet:

1) We don't know for sure that it can generate stuff that will plug into
the current templating system.

2) bric can generate navigation, we know that. But can it generate
nativation that integrates well with what we have now?

3) How does bric handle the logins? Right now there is one login for the
/admin/ stuff, but it's not exactly flexible to maintain the passwords
there. And we need some kind of "unified login system" between the
different parts IMHO - so you don't need a separate account to
edit/submit doc comments from editing techdocs pages.



In general, I'm also not convinced unless we have a person who *knows*
Mason (or whatever else you chose to use - IIRC bric can do different
templating engines)  who is willing to commit time *not just to get
things started*. The web project has kind of a history with people
getting started and then leaving. Only fairly few people tend to stick
around and maintain it in the long run.
Granted this can be an argument *for* a common CMS, but then it has to
be a CMS that people already know. Either people who work on the stuff
now (who *know* the current system - at least to some degree) or new
people that will actually *stick around*.



That said, personally I think people are vastly overestimating the work
needed to just stick a WYSIWYG editor into the current framework and be
done with it. I know I did one of these for work a couple of weeks back,
and it took me *2 hours*. I looked into using it straight up for the
postgresql site, but I got stuck on the HTML validation stuff.
And I also think peopel are vastly *underestimating* the work needed to
get a "stock CMS" to "play nice" with what we already have.

The stuff I did for work is in C#, and it really is a breeze to validate
the resulting HTML there. I'm sure that can be done fairly easy in PHP,
but I'm not good enough with that. If someone can get something together
to validate the HTML (that it's both valid and only contains tags we
want - we don't want people XSSing us, for example), then the rest is
*easy*.

The only thing to deal with is how to do the navigation, but that's a
problem regardless of how it's done. The nav templates as they are now
don't really deal with a whole lot of documents in a tree structure. But
I'm sure something can be done relatively easy here - as Gavik has
already shown.

(BTW, for a easy-to-use, completely plug-in, WYSIWYG editor, that is BSD
licensed, go to http://www.dynarch.com/projects/htmlarea/. If I could
plug it into my intranet using C#/.Net and MSIE only, it should be
*easy* to get it running on our open systems.


//Magnus