CMS
Gerrit Kuehn
03 Jul 08 19:24, Tobias Crefeld wrote to Gerrit Kuehn:
GK>> Hier ist ja auch gerade mal wieder gar nichts los... hat jemand
GK>> Interesse, sich über CMS-Systeme zu unterhalten? Ich habe auf der
TC> Buuhhh,, offtopich - schreib Dir sofort selbst nen Complaint! ;)
Ne, völlig ontopic. Soll schließlich alles unter *ix laufen.
TC> War da schon etwas unterwegs. Ganz witzig finde ich die Moeglichkeit
TC> bei
TC> ISP wie 1blu, die jede Menge vorgefertigte CMS praktisch auf
TC> Knopfdruck
TC> einrichten. Zum Rumspielen nicht schlecht. Sind allerdings auf PHP
TC> fixiert.
Ich brauche und habe einen eigenen Rechner dafür. php wäre also möglich,
ist aber keine Pflicht (ebensowenig mysql & co.).
TC> Bei den WCMS wird es dann reichhaltig, erst recht wenn PHP und MySQL
TC> kein
TC> Muss ist (bei managed-webhosting ist man da meist limitiert).
Wie gesagt, auf jeden Fall mit eigenem Rechner.
TC> Es gibt Systeme, die eher auf gemeinsames Arbeiten an einem Dokument
TC> ausgelegt, was natuerlich in erster Linie Wiki umfasst, aber auch
TC> Scoop
TC> oder Drupal bieten hier einiges. Das sattsam bekannte Mediawiki hat
TC> insbesondere den Vorteil, dass es hierfuer mittlerweile eine Menge
TC> Module
TC> gibt, auch um Funktionen anderer Websites wie Google einzubinden. Von
TC> Haus
TC> aus sind die Moeglichkeiten allerdings eher bescheiden, aber dafuer
TC> kann
TC> man sehr schnell loslegen. Mit einer Kruecke kann man sogar
TC> Benutzerverwaltung und geschuetzte Dokumente einrichten.
Gemeinsame Dokumentbearbeitung ist nett, aber kein Muß. Ein genaues
Anforderungsprofil habe ich leider nicht, das wird vermutlich erst im
Betrieb entstehen. Von daher wäre ein System mit entsprechender
Flexibilität gut.
Grundsätzlich soll es sich um ein Dokumentationssystem handeln, auf dem von
verschiedenen Usern vor allem verschiedene Arten von Dokumenten und anderen
Informationen abgelegt und (wichtig!) auch wiedergefunden werden können.
Revisionierung wäre in diesem Zusammenhang nett, ein Indizieren der
abgelegten Dokumente (fulltext zumindest für gängige Sachen wie pdf, doc,
ppt) ist ein Muß.
TC> Dann gibt es Zeitungssoftware, die insbesondere Schreiben,
TC> Formatierung
TC> und Bewerten von Artikeln durch eine Redaktion bietet. Da faellt mir
TC> als
TC> erstes Joomla ein. Das bietet Mehrbenutzerfaehigkeit, allerdings nur
TC> hinsichtlich Texterstellung. Das Design bleibt in einer Hand und die
TC> Hierarchie bleibt eindimensional - also keine Loesung, wenn man den
TC> Zugriff zwischen Abteilungen trennen will.
Das ist nicht so meine Baustelle. Joomla war glaube ich auch ziemlich
verseucht mit Sicherheitslücken, wenn ich mich richtig erinnere.
TC> Sehr viel Freiheiten bietet Typo3. Da kann man ebensogut ein
TC> Zeitungsarchiv draus machen wie eine Website, bei der viele Gruppen
TC> ihre
TC> eigene Rubrik haben. Nachteil: Der Einstiegslevel ist sehr hoch.
Ja, das hatte ich mir angesehen, es aber für zu klompiziert gehalten.
TC> Vorteil:
TC> Es gibt fuer dieses Programm viele Agenturen und Freelancer, die
TC> professionelle Unterstuetzung bieten oder gleich noch ein managed-
TC> webhosting samt Applikationspflege dafuer bieten.
Scheidet aus, das wird sicher nicht nach außen vergeben.
TC> Plone habe ich zwar 2..3 x live gesehen, aber nie selber damit
TC> gearbeitet.
TC> Es scheint deutlich fluessiger zu bedienen sein. Nicht
TC> vorkompiliertes PHP
TC> hat da einfach ein prinzipielles Handicap gegenueber
TC> Applikationsservern.
Ich hatte bei plone zunächst auch den Eindruck, daß es wie typo3 zu mighty
und zu kompliziert ist.
Installation und Testbetrieb waren dann aber doch ganz positiv, so daß das
im Moment mein heißester Kandidat ist.
TC> Privat verwende ich hauptsaechlich Mediawiki und Joomla, aber ein
TC> bisserl
TC> habe ich auch schon mit Drupal, Typo3 und Wordpress gewerkelt (im
TC> Prinzip
TC> kann man auch Blogsoftware als CMS verwenden). Ein WCMS mit Zope
TC> hatte ich
TC> auch mal in den Fingern, aber das lief ohne Plone, also quasi
TC> "direkt" auf
TC> dem Applikationsserver.
Ich habe wie gesagt Erfahrungen mit Tiki und ein bißchen mit Wordpress. Im
Vergleich zu Plone wirken die aber ehrlich gesagt alle zusammengefrickelt.
Regards,
Gerrit
Tobias Crefeld
TC>> War da schon etwas unterwegs. Ganz witzig finde ich die Moeglichkeit
TC>> bei
TC>> ISP wie 1blu, die jede Menge vorgefertigte CMS praktisch auf
TC>> Knopfdruck
TC>> einrichten. Zum Rumspielen nicht schlecht. Sind allerdings auf PHP
TC>> fixiert.
GK> Ich brauche und habe einen eigenen Rechner dafür. php wäre also
GK> möglich, ist aber keine Pflicht (ebensowenig mysql & co.).
Es ging mir da auch nur ums Ausprobieren, da man bei 1blu mit wenigen
Mausklicks viele Installationen parallel einrichten kann, um sie
anschliessend zu testen. Leider bietet nicht jedes CMS eine Test-
Installation, wo man Moeglichkeiten und L&F ausprobieren kann - da kann
diese Alternative interessant sein.
TC>> Es gibt Systeme, die eher auf gemeinsames Arbeiten an einem Dokument
TC>> ausgelegt, was natuerlich in erster Linie Wiki umfasst, aber auch
TC>> Scoop
TC>> oder Drupal bieten hier einiges. Das sattsam bekannte Mediawiki hat
TC>> insbesondere den Vorteil, dass es hierfuer mittlerweile eine Menge
TC>> Module
TC>> gibt, auch um Funktionen anderer Websites wie Google einzubinden. Von
TC>> Haus
TC>> aus sind die Moeglichkeiten allerdings eher bescheiden, aber dafuer
TC>> kann
TC>> man sehr schnell loslegen. Mit einer Kruecke kann man sogar
TC>> Benutzerverwaltung und geschuetzte Dokumente einrichten.
GK> Gemeinsame Dokumentbearbeitung ist nett, aber kein Muß. Ein genaues
GK> Anforderungsprofil habe ich leider nicht, das wird vermutlich erst im
GK> Betrieb entstehen. Von daher wäre ein System mit entsprechender
GK> Flexibilität gut.
Das wuerde ich unbedingt vor Inbetriebnahme abklopfen. Vielleicht erstmal
einen Piloten im kleinen Kreis aufsetzen und dann erstmal zusammentragen,
wer was moechte. Ansonsten hast Du sehr schnell grosse Datenmengen, die Du
nicht mehr mit akzeptablen Aufwand migriert bekommst, weil Export- oder
Importschnittstellen fuer die Inhalte fehlen.
Ein relativ hohes Mass an Flexibilitaet bietet Drupal. Ein Artikel heisst
dort "node" und der kann dann von einer statischen Webseite ueber eine
Buchseite bis zum Forenbeitrag alles Moegliche sein. Es bietet auch
verschiedene Moeglichkeiten, ueber Kategorisierung oder Taxonomien Ordnung
in den Content zu bringen.
Dazu gibt es auch Schnittstellen zum Einbinden eigener Module, was bei
Vorhandensein entsprechender PHP-Kenntnisse einen (wenn auch aufwendigen)
Weg bietet, fehlende Funktionen nachzuruesten.
GK> Grundsätzlich soll es sich um ein
GK> Dokumentationssystem handeln, auf dem von verschiedenen Usern vor
GK> allem verschiedene Arten von Dokumenten und anderen Informationen
GK> abgelegt und (wichtig!) auch wiedergefunden werden können.
GK> Revisionierung wäre in diesem Zusammenhang nett, ein Indizieren der
GK> abgelegten Dokumente (fulltext zumindest für gängige Sachen wie pdf,
GK> doc, ppt) ist ein Muß.
Das ist dann eigentlich ein Dokumentenmanagementsystem. In der iX 07/08
war dazu ein Artikel uber Alfresco:
http://www.alfresco.com/de/
Laeuft eigentlich unter ECMS, soll aber auch ein Webinterface fuer die
Aussendarstellung von Projekt/Firma/Arbeitsgruppe bieten. Verteiltes
Arbeiten kann man ja auch ueber WebDAV oder irgendwelche VPNs realisieren.
Die Integration in Office-Umgebungen ist bei solchen Systemen deutlich
fortgeschrittener als dies bei WCMS der Fall ist, bei denen Office-Formate
wie Medienbrueche behandelt werden.
Mit einigen Einschraenkungen (was die Office-Formate betrifft) waere auch
mediawiki, insbesondere mit der semantic-Erweiterung einsetzbar:
http://semanticweb.org/wiki/Semantic_MediaWiki
Die Seite bietet insbesondere auch einen guten, vorbereitenden Einstieg,
um sich klar zu werden, in welchem Umfang diese Zusatzfunktionalitaet fuer
Deine Anforderung hilfreich ist. Einen ausfuehrlicheren Artikel dazu
findet man auch unter
http://www.gi-ev.de/service/informatiklexikon/informatiklexikon-
detailansicht/meldung/174/
TC>> Dann gibt es Zeitungssoftware, die insbesondere Schreiben,
TC>> Formatierung und Bewerten von Artikeln durch eine Redaktion bietet.
TC>> Da faellt mir als erstes Joomla ein. Das bietet
TC>> Mehrbenutzerfaehigkeit, allerdings nur hinsichtlich Texterstellung.
TC>> Das Design bleibt in einer Hand und die Hierarchie bleibt
TC>> eindimensional - also keine Loesung, wenn man den Zugriff zwischen
TC>> Abteilungen trennen will.
GK> Das ist nicht so meine Baustelle. Joomla war glaube ich auch ziemlich
GK> verseucht mit Sicherheitslücken, wenn ich mich richtig erinnere.
Generell darf alles, was mit PHP realisiert wird, als staerker gefaehrdet
gelten. Joomla ist einfach besonders stark verbreitet und entsprechend
werden Sicherheitslecks dort schneller bekannt. Im Gegensatz zu Projekten
wie Wordpress ist es aber geradezu eine Insel der Glueckseligen, zumal
Patches zeitnah erfolgen. Fuer Deine obengenannten Anforderungen erscheint
es jedenfalls ungeeignet.
TC>> Sehr viel Freiheiten bietet Typo3. Da kann man ebensogut ein
TC>> Zeitungsarchiv draus machen wie eine Website, bei der viele Gruppen
TC>> ihre eigene Rubrik haben. Nachteil: Der Einstiegslevel ist sehr hoch.
GK> Ja, das hatte ich mir angesehen, es aber für zu klompiziert gehalten.
Es ist auf alle Faelle ein reines WCMS und somit nach Deinen obigen
Anforderungen ungeeignet. Es boete immerhin eine vernuenftige
Gruppenverwaltung, was bei WCMS meist stiefmuetterlich behandelt wird.
TC>> Vorteil:
TC>> Es gibt fuer dieses Programm viele Agenturen und Freelancer, die
TC>> professionelle Unterstuetzung bieten oder gleich noch ein managed-
TC>> webhosting samt Applikationspflege dafuer bieten.
GK> Scheidet aus, das wird sicher nicht nach außen vergeben.
Dann habt Ihr hoffentlich bereits erfahrene Applikateure oder viel Zeit
und Musse. Fuer den initialen Einstieg in ein CMS ist es ein steiniger
Weg, auf erfahrene Hilfe zu verzichten.
TC>> Privat verwende ich hauptsaechlich Mediawiki und Joomla, aber ein
TC>> bisserl habe ich auch schon mit Drupal, Typo3 und Wordpress gewerkelt
TC>> (im Prinzip kann man auch Blogsoftware als CMS verwenden). Ein WCMS
TC>> mit Zope hatte ich auch mal in den Fingern, aber das lief ohne Plone,
TC>> also quasi "direkt" auf dem Applikationsserver.
GK> Ich habe wie gesagt Erfahrungen mit Tiki und ein bißchen mit
GK> Wordpress. Im Vergleich zu Plone wirken die aber ehrlich gesagt alle
GK> zusammengefrickelt.
Eigentlich steckt hinter jedem CMS eine primaere Anforderung, fuer die das
CMS dann bei aller eventuellen Offenheit konzipiert ist. Diese primaere
Anforderung und damit Zielsetzung heisst es erstmal herauszufinden.
Man kann natuerlich auch andere CMS verwenden und auf den gewuenschten
Fokus umbiegen, aber das wird immer etwas sperrig wirken oder sehr viel
Aufwand erfordern. Dazu kommt, dass manche Software zwar ganz passabel
funktioniert, aber mit bescheidenem Design daherkommt, was sich aber im
Zeitalter von CSS und PHP-templates mit akzeptablen Aufwand reparieren
laesst.
Gruss,
Tobias.
Gerrit Kuehn
15 Jul 08 21:12, Tobias Crefeld wrote to Gerrit Kuehn:
TC> Es ging mir da auch nur ums Ausprobieren, da man bei 1blu mit wenigen
Ihgitt, das böse Word. Bitte nicht mehr 1blu sagen! ;-)
GK>> Gemeinsame Dokumentbearbeitung ist nett, aber kein Muß. Ein genaues
GK>> Anforderungsprofil habe ich leider nicht, das wird vermutlich erst im
GK>> Betrieb entstehen. Von daher wäre ein System mit entsprechender
GK>> Flexibilität gut.
TC> Das wuerde ich unbedingt vor Inbetriebnahme abklopfen. Vielleicht
Können vor lachen...
TC> erstmal
TC> einen Piloten im kleinen Kreis aufsetzen und dann erstmal
TC> zusammentragen,
TC> wer was moechte. Ansonsten hast Du sehr schnell grosse Datenmengen,
TC> die Du
TC> nicht mehr mit akzeptablen Aufwand migriert bekommst, weil Export-
TC> oder
TC> Importschnittstellen fuer die Inhalte fehlen.
Deswegen habe ich ja derzeit Testinstallationen von tiki und plone laufen.
Von meiner Seite aus sieht plone wesentlich besser aus. Mal sehen, was die
User dazu sagen...
GK>> Grundsätzlich soll es sich um ein
GK>> Dokumentationssystem handeln, auf dem von verschiedenen Usern vor
GK>> allem verschiedene Arten von Dokumenten und anderen Informationen
GK>> abgelegt und (wichtig!) auch wiedergefunden werden können.
GK>> Revisionierung wäre in diesem Zusammenhang nett, ein Indizieren der
GK>> abgelegten Dokumente (fulltext zumindest für gängige Sachen wie pdf,
GK>> doc, ppt) ist ein Muß.
TC> Das ist dann eigentlich ein Dokumentenmanagementsystem. In der iX
TC> 07/08
TC> war dazu ein Artikel uber Alfresco:
TC> http://www.alfresco.com/de/
TC> Laeuft eigentlich unter ECMS, soll aber auch ein Webinterface fuer
TC> die
TC> Aussendarstellung von Projekt/Firma/Arbeitsgruppe bieten. Verteiltes
TC> Arbeiten kann man ja auch ueber WebDAV oder irgendwelche VPNs
TC> realisieren.
Ich habe gerade mal einen Blick auf die Specs geworfen. JBoss und Tomcat
sind natürlich auch erstmal Brocken. So auf den ersten Blick sehe ich keine
größeren Vorteile gegenüber zope/plone.
TC> Die Integration in Office-Umgebungen ist bei solchen Systemen
TC> deutlich
TC> fortgeschrittener als dies bei WCMS der Fall ist, bei denen
TC> Office-Formate
TC> wie Medienbrueche behandelt werden.
Die Office-Anbindung ist wie gesagt gar nicht so wichtig. WebDAV habe ich
für plone auch noch nicht eingerichtet, aber das mache ich demnächst sicher
noch. Wir sind ja eigentlich ein Forschungsinstitut und benötigen etwas zur
Dokumentation ein größeren Experimentes, das über sicher 10 Jahre betrieben
werden soll.
TC> Deine Anforderung hilfreich ist. Einen ausfuehrlicheren Artikel dazu
TC> findet man auch unter
TC> http://www.gi-ev.de/service/informatiklexikon/informatiklexikon-
TC> detailansicht/meldung/174/
Das sehe ich mich nochmal um, thnx.
TC> Generell darf alles, was mit PHP realisiert wird, als staerker
TC> gefaehrdet
TC> gelten. Joomla ist einfach besonders stark verbreitet und
TC> entsprechend
TC> werden Sicherheitslecks dort schneller bekannt. Im Gegensatz zu
TC> Projekten
TC> wie Wordpress ist es aber geradezu eine Insel der Glueckseligen,
TC> zumal
TC> Patches zeitnah erfolgen. Fuer Deine obengenannten Anforderungen
TC> erscheint
TC> es jedenfalls ungeeignet.
Nach dem, was ich bis jetzt in tikiwiki an php gesehen habe, möchte ich
auch schon gar nicht mehr mit der Sprache zu tun haben. :-)
Dann lerne ich doch lieber Python.
TC>>> Vorteil:
TC>>> Es gibt fuer dieses Programm viele Agenturen und Freelancer, die
TC>>> professionelle Unterstuetzung bieten oder gleich noch ein managed-
TC>>> webhosting samt Applikationspflege dafuer bieten.
GK>> Scheidet aus, das wird sicher nicht nach außen vergeben.
TC> Dann habt Ihr hoffentlich bereits erfahrene Applikateure oder viel
TC> Zeit
TC> und Musse. Fuer den initialen Einstieg in ein CMS ist es ein
TC> steiniger
TC> Weg, auf erfahrene Hilfe zu verzichten.
Der Vorteil an plone wäre, das unser anderes Teilinstitut bereits damit
arbeitet. Das habe ich allerdings erst mitbekommen, nachdem ich mich für
eine Testinstallation entschieden hatte (und ich habe auch immer noch nicht
herausbekommen, wer da genau was mit macht - ist halt Urlaubszeit :-).
Regards,
Gerrit
Tobias Crefeld
GK>>> Gemeinsame Dokumentbearbeitung ist nett, aber kein Muß. Ein genaues
GK>>> Anforderungsprofil habe ich leider nicht, das wird vermutlich erst
GK>>> im Betrieb entstehen. Von daher wäre ein System mit entsprechender
GK>>> Flexibilität gut.
TC>> Das wuerde ich unbedingt vor Inbetriebnahme abklopfen. Vielleicht
GK> Können vor lachen...
Wie meinen?
GK>>> Grundsätzlich soll es sich um ein
GK>>> Dokumentationssystem handeln, auf dem von verschiedenen Usern vor
GK>>> allem verschiedene Arten von Dokumenten und anderen Informationen
GK>>> abgelegt und (wichtig!) auch wiedergefunden werden können.
GK>>> Revisionierung wäre in diesem Zusammenhang nett, ein Indizieren der
GK>>> abgelegten Dokumente (fulltext zumindest für gängige Sachen wie pdf,
GK>>> doc, ppt) ist ein Muß.
TC>> Das ist dann eigentlich ein Dokumentenmanagementsystem. In der iX
TC>> 07/08 war dazu ein Artikel uber Alfresco:
TC>> http://www.alfresco.com/de/
GK> Ich habe gerade mal einen Blick auf die Specs geworfen. JBoss und
GK> Tomcat sind natürlich auch erstmal Brocken. So auf den ersten Blick
GK> sehe ich keine größeren Vorteile gegenüber zope/plone.
Kann Plone ppt-Format indizieren?
ECMS wie Alfresco haben eine ganz andere Zielsetzung als ein WCMS wie
plone oder Drupal. Willst Du eine Betrieb darstellen und dafuer Websites
produzieren, suchst Du Moeglichkeiten des kollaborativen, webbasierten
Arbeitens oder willst Du eine Bibliothek anlegen, um dort Dokumente
abzulegen? Ob der Applikationsserver JBoss oder Zope heisst, sollte egal
sein, wenn es einem auf die damit erzielten Funktionen ankommt. Wenn Du
bereits Erfahrungen mit groesseren Zope-Installationen hast, dann mag das
ein Argument fuer Zope sein.
Ansonsten unterscheiden sich beide mehr in der Programmiersprache als in
der grundsaetzlichen Funktion. Die aber ist nur dann wirklich relevant,
wenn man selber Programmentwicklung betreiben will. Ob man _dann_ lieber
auf Python (Zope) oder auf Java (JBoss, Tomcat) setzt, wird neben dem
Umfang der bisherigen Vorkenntnisse sicher auch eine strategische
Entscheidung sein. Insbesondere Pascal-Fans tun sich mit Python leichter.
Java hat dagegen sicher den hoeheren Verbreitungsgrad.
Tomcat ist auch nur eine Art Webserver, der entweder solo oder als Instanz
von Apache betrieben wird. Novell arbeitet schon seit vielen Jahren mit
Tomcat als Plattform fuer seine webbasierten Anwendungen, ohne dass dies
fuer die meisten Administratoren offensichtlich waere.
TC>> Die Integration in Office-Umgebungen ist bei solchen Systemen
TC>> deutlich fortgeschrittener als dies bei WCMS der Fall ist, bei denen
TC>> Office-Formate wie Medienbrueche behandelt werden.
GK> Die Office-Anbindung ist wie gesagt gar nicht so wichtig. WebDAV habe
"wie gesagt"?
Oben hattest Du noch geschrieben, dass ppt, doc und pdf nicht nur
revisioniert, sondern auch noch indiziert werden soll. Das scheinen mir
uebliche Office-Formate zu sein und wenn da keine filebasierte Integration
vorhanden ist, duerfen die Anwender jede Datei zu Fuss hochladen, was sie
sicher nicht lange mitmachen.
GK> ich für plone auch noch nicht eingerichtet, aber das mache ich
GK> demnächst sicher noch. Wir sind ja eigentlich ein Forschungsinstitut
GK> und benötigen etwas zur Dokumentation ein größeren Experimentes, das
GK> über sicher 10 Jahre betrieben werden soll.
Achso, das erklaert natuerlich einiges. Dachte zunaechst, es sollte was
Produktives werden.
TC>> Generell darf alles, was mit PHP realisiert wird, als staerker
TC>> gefaehrdet gelten.
GK> Nach dem, was ich bis jetzt in tikiwiki an php gesehen habe, möchte
GK> ich auch schon gar nicht mehr mit der Sprache zu tun haben. :-) Dann
GK> lerne ich doch lieber Python.
Sollte eigentlich so oder so nicht noetig sein. Ein CMS, egal welcher
Couleur sollte in der Regel ein fertiges Programmpaket sein, dass keine
Programmierkenntnisse erfordert.
TC>> Dann habt Ihr hoffentlich bereits erfahrene Applikateure oder viel
TC>> Zeit und Musse. Fuer den initialen Einstieg in ein CMS ist es ein
TC>> steiniger Weg, auf erfahrene Hilfe zu verzichten.
GK> Der Vorteil an plone wäre, das unser anderes Teilinstitut bereits
GK> damit arbeitet. Das habe ich allerdings erst mitbekommen, nachdem ich
GK> mich für eine Testinstallation entschieden hatte (und ich habe auch
GK> immer noch nicht herausbekommen, wer da genau was mit macht - ist halt
GK> Urlaubszeit :-).
Ich denke, Deine Entscheidung ist bereits gefallen und nach allem, was ich
aus F+E-Bereichen mitbekommen habe, spielen dort Zeit und Effizienz eine
genuegend geringe Rolle, dass so eine Entscheidung nicht den
grundsaetzlichen Stellenwert hat, den es ansonsten in Firmen hat - oder
haben sollte.
Gruss,
Tobias.
Gerrit Kuehn
17 Jul 08 16:49, Tobias Crefeld wrote to Gerrit Kuehn:
TC>>> Das wuerde ich unbedingt vor Inbetriebnahme abklopfen. Vielleicht
GK>> Können vor lachen...
TC> Wie meinen?
Dafür müßten die Leute, die sapäter damit arbeiten, eine genaue Vorstellung
äußern, was sie denn eigentlich machen wollen...
GK>> Ich habe gerade mal einen Blick auf die Specs geworfen. JBoss und
GK>> Tomcat sind natürlich auch erstmal Brocken. So auf den ersten Blick
GK>> sehe ich keine größeren Vorteile gegenüber zope/plone.
TC> Kann Plone ppt-Format indizieren?
Nicht out-of-the-box (da geht nur pdf und doc), läßt sich aber nachrüsten.
TC> ECMS wie Alfresco haben eine ganz andere Zielsetzung als ein WCMS wie
TC> plone oder Drupal. Willst Du eine Betrieb darstellen und dafuer
Also plone selbst bezeichnet sich durchaus als ecms (auch wenn ich da keine
wirklich scharfen Grenzen sehe).
TC> Ansonsten unterscheiden sich beide mehr in der Programmiersprache als
TC> in
TC> der grundsaetzlichen Funktion. Die aber ist nur dann wirklich
TC> relevant,
TC> wenn man selber Programmentwicklung betreiben will. Ob man _dann_
TC> lieber
TC> auf Python (Zope) oder auf Java (JBoss, Tomcat) setzt, wird neben dem
TC> Umfang der bisherigen Vorkenntnisse sicher auch eine strategische
TC> Entscheidung sein. Insbesondere Pascal-Fans tun sich mit Python
TC> leichter.
TC> Java hat dagegen sicher den hoeheren Verbreitungsgrad.
Meiner eher leidvollen Erfahrung nach will/muß man früher oder später immer
selber an solchen Dingern herumprogrammieren oder zumindest debuggen
können. Pascal konnte ich früher mal, in den letzten Jahren habe ich
meistens Java gemacht. Nach einem ersten Blick würde ich mich sehr viel
lieber in Python einarbeiten als in php (was zu Deinem Kommentar bzgl.
Python und Pascal paßt :-).
TC> Tomcat ist auch nur eine Art Webserver, der entweder solo oder als
TC> Instanz
TC> von Apache betrieben wird. Novell arbeitet schon seit vielen Jahren
TC> mit
TC> Tomcat als Plattform fuer seine webbasierten Anwendungen, ohne dass
TC> dies
TC> fuer die meisten Administratoren offensichtlich waere.
Ich weiß, ich weiß. Ich sehe nur schon den Zeitpunkt voraus, an dem ich
gebeten werde, mal was hinter diesen Kulissen zu machen...
GK>> Die Office-Anbindung ist wie gesagt gar nicht so wichtig. WebDAV habe
TC> "wie gesagt"?
TC> Oben hattest Du noch geschrieben, dass ppt, doc und pdf nicht nur
TC> revisioniert, sondern auch noch indiziert werden soll. Das scheinen
TC> mir
TC> uebliche Office-Formate zu sein und wenn da keine filebasierte
TC> Integration
TC> vorhanden ist, duerfen die Anwender jede Datei zu Fuss hochladen, was
TC> sie
TC> sicher nicht lange mitmachen.
Warum nicht? Da hätte ich erstmal keine Bauchschmerzen mit.
GK>> ich für plone auch noch nicht eingerichtet, aber das mache ich
GK>> demnächst sicher noch. Wir sind ja eigentlich ein Forschungsinstitut
GK>> und benötigen etwas zur Dokumentation ein größeren Experimentes, das
GK>> über sicher 10 Jahre betrieben werden soll.
TC> Achso, das erklaert natuerlich einiges. Dachte zunaechst, es sollte
TC> was
TC> Produktives werden.
?
Das ist produktiv. Damit sollen sicher 1-2 Dutzend Leute über Jahre mehr
oder weniger täglich arbeiten.
GK>> Nach dem, was ich bis jetzt in tikiwiki an php gesehen habe, möchte
GK>> ich auch schon gar nicht mehr mit der Sprache zu tun haben. :-) Dann
GK>> lerne ich doch lieber Python.
TC> Sollte eigentlich so oder so nicht noetig sein. Ein CMS, egal welcher
TC> Couleur sollte in der Regel ein fertiges Programmpaket sein, dass
TC> keine
TC> Programmierkenntnisse erfordert.
Das war bei tiki anders.
GK>> Der Vorteil an plone wäre, das unser anderes Teilinstitut bereits
GK>> damit arbeitet. Das habe ich allerdings erst mitbekommen, nachdem ich
GK>> mich für eine Testinstallation entschieden hatte (und ich habe auch
GK>> immer noch nicht herausbekommen, wer da genau was mit macht - ist
GK>> halt Urlaubszeit :-).
TC> Ich denke, Deine Entscheidung ist bereits gefallen und nach allem,
TC> was ich
TC> aus F+E-Bereichen mitbekommen habe, spielen dort Zeit und Effizienz
TC> eine
TC> genuegend geringe Rolle, dass so eine Entscheidung nicht den
TC> grundsaetzlichen Stellenwert hat, den es ansonsten in Firmen hat -
TC> oder
TC> haben sollte.
Natürlich spielen Zeit und Effizienz eine Rolle. Ich fange bzgl. cms aber
bei Null an, weil bis jetzt noch keins im Einsatz ist. Das
Anforderungsprofil ist hinreichend diffus, ein paar Sachen habe ich mir
angesehen und ausprobiert. Nach dem, was Du geschrieben hast, könnten
drupal und alfresco noch einen Blick wert sein. Wenn ich noch Zeit habe und
User zum Testen begeistern kann, mache ich in der Richtung auch nochmal
was. Aber beliebig lange kann das Testen nicht mehr gehen, das muß auch
demnächst mal in den Betrieb gehen.
Regards,
Gerrit