Hi there!
comments inline....
Lars Nooden wrote:
On 06/28/2010 03:14 PM, Bernd Eilers wrote:
Surley everyone uses CSS nowadays and this will surely stay the same
with the new website.
That, I hope, goes without saying. I mention XHTML + CSS explicity
because it may be adequate or even desirable to use them without a CMS
in conjunction with SSI and a versioning system like CVS and friends.
There a dozens of webframeworks and technics to "decorate" webpages with
header footer and standard navigation elements used out there. SSI maybe
just one of the simpler and older things.
It is among the simplest, most resource efficient, easier to use things.
... There´s surly much more dynamic things on a website like OOo ...
Please elaborate on what you mean by 'dynamic' I'm seeing the site as a
means of publication.
There is a lot of "non-static" content on a website like OOo. Stuff
which is based on who is the user currently being logged in, which
access privileges and roles in projects has he/she, which projects do we
currently have, which mailinglists do we currently have, who is
subscribed to which mailinglist, what are the contents of the
mailinglist, what are the access rights and other settings for the
mailing list, which files have been recently added to a project, etc., etc.
The information for generating such dynamic content is typically stored
in a database and things like JavaServlets, JavaServerPages, ruby on
rails or perl are used to generate webpages interacting with the database.
There may also be some dynamic content inside the "decoration" of an
otherwise static webpage eg. displaying the username in the header or
elements depending on the members roles in projects inside the added
navigational elements.
Kenai uses ruby on rails. (http://rubyonrails.org/). Collabnet uses java
servlets.
Both rubyonrails and jsp are fine, the devil is in the details of
implementation.
For the Source Code Managment System used to store the website content
the plan is to move from CVS to SubVersion with the Kenai Migration.
SVN, Git, Mercurial, or Bazaar are fine.
Any of them can be used with XHTML+CSS
Note that I am not saying we can´t start to experiment with a new look
and feel using prototypes which are just based on CVS, CSS, SSI etc.
Again, these are two different topics
1. the New Look And Feel,
2. the publication framework
Well you can not completely separte them if you want to provide a that´s
one thing I am using experience.
And it is not only a publication framework it´s also a collaboration
tool ;-)
While Kenai project is being worked on, XHTML+CSS+SSI lets the work get
done for the OOo project. The sites can be grabbed as-is using wget (or
other harvester) recursively. Then footers, headers, menus can be made
for each OOo sub-project and links substituted.
Well for prototyping yes. But a real thing does need more than SSI to
handle all the dynamic stuff. And you certainly want to use the pages
from CVS without the decoration or grab/wget their /nonav/ version and
not really duplicate header, footer, etc on each page of course.
My
concern though is that if we really would switch to a new look and feel
which could be considered a major redesign and not just small adaption
to new branding before the kenai migration most of the work put so far
into providing the CURRENT look&feel on the kenai infrastructure would
well have been done for the trash :-(
That would be sad, but there are also times to cut losses and not throw
good money (or time) after bad. One expression translated from Swedish
is 'the cost of learning'. Or "Plan to throw one away; you will anyway"
is from Brooks' The Mythical Man-Month.
Well sad but true, yes.
Funny to hear you referencing "The Mythical Man-Month" and estimating
efforts in hours though ;-)
The templates, if
they are just a port of the current OOo Look & Feel, can be done in a
few weeks -- even allowing for tremendous time padding for meetings and
phone tag.
From what I have done so far I have experienced quite a lot items where
the current OOo stylesheets had some definitions which did interfere
with kenai webpages in a way that it destroyed their look which had to
be resolved by explicitly overriding too broad implicit CSS definitions
of the OOo stylesheet on a kenai theme page.
Creating a general method for "decorating" the normal OOo webpages is
maybe the simpler part where more work is involved is to resolve CSS
Conflicts when mixing OOo CSS and kenai CSS on kenai provided web
content, like eg. the dynmacally generated list of projects or the also
dynamically generated list of mailinglists on a project etc.
You may note that even the current website does already dynamically add
header footer, navigational elements and CSS to webpages stored in the CVS.
Yes, I noticed ;)
http://qa.openoffice.org/issues/show_bug.cgi?id=77961
Well with kenai we will hopefully have some more influence on what gets
inserted where and which pages need an exception that nothing is being
inserted at all etc. Well I say I hope so!
IMHO the task of dynamically adding header footers, navigational
elements and CSS to webpages stored in the CVS is the role of SSI. Add
a few SSI links in each document and the effect is the same, but with
higher performance and lower maintenance.
SSI at least not alone can not create content depending on roles users
have in projects and similar things. SSI alone is just not powerful enough.
The mailing list can be managed by GNU Mailman. Tweaking that to match
the current OOo Look & Feel can be done in a few hours.
Kenai uses sympa (http://www.sympa.org) for mailing lists which is also
a mailing list manager under GNU General Public License and may have
some advantages and disadvantages when compared to GNU Mailman. I am not
much into details on both of those mailing list managers so can really
compare them.
*upps* made a typo there that should have been "so can not really
compare them" of course.
Thanks. That one is new to me. It is very hard to find out new
worthwile programs nowadays due to the nearly complete lack of press
coverage. Looking at the documentation for sympa, it addresses the
concern about modularity which is reason for mentioning MLM at all.
The phase out
of the old list manager can be done starting one list at a time, growing
to several at a time, over a few weeks, mostly by fiddling with DNS MX
entries.
The current idea is to initially get mbox files from collabnet migrate
them to sympas mailing list archive files and than incrementally upgrade
those by grabbing new content from the collabnet website frontend to the
mailing list archive.
+1
The bug tracking can be managed by any ticketing system: RT, Bugzilla,
OTRS, Trac or Redmine. Tweaking that to match the current OOo Look &
Feel can be done in a few hours.
The plan is to switch to bugzilla. On the kenai infrastructure bugzilla
and Jira are the two options for bugtracking. If you think you can
really tweak bugzilla in a few hours you are welcome to help doing that
task ;-) altough I would think it will need some more effort.
When I tried tweaking the appearance of it in 2001 or so it took only a
few hours (after initial set up) to add banners, etc.
Well that´s nice to hear.
/Lars
Kind regards,
Bernd Eilers
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
