Anderes Wiki einbinden

SarahMischelle 2009-08-11 20:30:46 UTC #1

Hallo,

mich würde mal interessieren, ob es möglich in EgW ein anders Wiki einzubinden? Bisher habe ich mit dem mitgelieferten Wiki immer nur Probleme.

Was müsste ich tun, um zb. Ein Mediawikki oder dein Dokuwiki einzubinden?

Gruß Sarah

Manfred_Kiss 2009-08-12 06:29:34 UTC #2

Hallo Sarah,

erst lesen, dann posten

Siehe bittte:

http://www.nabble.com/Externes-Program---MediaWiki-einbinden-to24863862s3741.html

Gruß

Manfred

SarahMischelle 2009-08-14 19:36:09 UTC #3

Oh,

ich hab vorher extra gesucht, aber nix gefunden.

Manchmal sieht man den Wald vor lauter Bäumen nicht.

Leider ist das nicht ganz das was ich meine.

Ich möchte das wiki nicht lose einbinden.

Eigentlich soll es eine Art Kombination werden. Ich würde gern das z.B. im, Mediawiki die Benutzerverwaltung vom egw verwendet wird. Also eigentlich soll das mediawiki anstelle des egwwikis fungieren, also intern verwendet werden.

Oder habe ich was falsch verstanden bei dem Wort “lose”.

Danke für den Link zum anderen Tread

Gruß Sarah

Hans-Jurgen_Tappe 2009-08-15 07:27:07 UTC #4

Hi!

SarahMischelle schrieb:

Eigentlich soll es eine Art Kombination werden. Ich würde gern das z.B. im,
Mediawiki die Benutzerverwaltung vom egw verwendet wird. Also eigentlich
soll das mediawiki anstelle des egwwikis fungieren, also intern verwendet
werden.

Das passiert auch bei “gallery”. Zur Integration musst Du mal dort die
Sourcen lesen un schauen, ob das beim Mediawiki auch funktionieren
könnte. Für einen festen Platz in eGroupware müsste MediaWiki die
verschiedenen Datenbank-Typen unterstützen. Wenn das der Fall ist, gibt’s
gute Chancen, das komplett und offiziell zu integrieren… Dann fragt
sich nur noch wer’s macht.

Grüße,
Hans-Jürgen

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Peter_Vratny-2 2009-08-15 09:41:52 UTC #5

Hans-Juergen Tappe wrote:

Das passiert auch bei “gallery”. Zur Integration musst Du mal dort die
Sourcen lesen un schauen, ob das beim Mediawiki auch funktionieren
könnte. Für einen festen Platz in eGroupware müsste MediaWiki die
verschiedenen Datenbank-Typen unterstützen. Wenn das der Fall ist, gibt’s

MediaWiki kann iirc keine ordentlichen Gruppen-/User-Konzepte abbilden
und ist daher imo ein schlechter Kandidat für eine Integration.

Als moinmoin-Fan kenn ich auf die Schnelle auch kein Wiki, dass meine
Ansprüchen als Integrations-Kandidat genügen würde .-)

mfg
Peter

–
Have you tried to turn it off and on again?
http://klicklich.at

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

4nndee 2009-08-17 18:20:46 UTC #6

Hast du mal überlegt die Wissensdatenbak zu verwenden?
Für diese gelten ja die Benutzerrechte.

Das Standard Wiki kann so weit ich weiß auch keine Rechte, man kann nr anonyme Zugriffe erlauben. Korrigiert mich bitte, falls ich mich irre.

SarahMischelle 2009-08-21 11:36:25 UTC #7

Hi,

danke für eure Antworten, auch wenn sie eher ernüchternd sind.

Wie sieht es mit DokuWiki aus? Dort gibt es auch ACL-Richtlinien (textbasiert) und das ganze braucht keine Datenbank. Es ist eine reine PHP-Anwendung.

Würde sich das nach eurer Meinung besser integrieren lassen?

Gruß Sarah

Stefan_Roder 2009-08-21 11:48:13 UTC #8

Hallo 4nndee,
du irrst: das Wiki kann gruppenspezifische und seitenbezogene Lese- und Schreibrechte vergeben., wobei natürlich fraglich ist, wofür das gut sein soll. Der Sinn eines Wiki ist ja gerade, dass alle zugreifen und vor allem auch ändern können. Insofern sollte man eine Einschränkung der Schreibrechte nur in besonderen Fällen in Betracht ziehen (z.B. Testumgebungen).
Schönen Gruss
Stefan Roder

Ralf_Becker_6 2009-08-21 13:16:14 UTC #9

Hi Sarah,

SarahMischelle schrieb:

Hi,

danke für eure Antworten, auch wenn sie eher ernüchternd sind.

Wie sieht es mit DokuWiki aus? Dort gibt es auch ACL-Richtlinien
(textbasiert) und das ganze brauch keine Datenbank. Es ist eine reine
PHP-Anwendung.

Würde sich das nach eurer Meinung besser integrieren lassen?

Nein, ein Filesystem statt Datenbank basierendes Wiki lässt sich nicht
besser intergrieren.

Am meisten Sinn macht für mich die per PEAR verfügbaren Wiki Engines,
die nur die Syntax von diversen Wiki’s zur Verfügung stellen (u.a.
Mediawiki). Dh. heißt allerdings nicht, das wir dafür im Moment Pläne
oder gar ein Budget hätten.

Die Diskussion nach einem Wiki Ersatz kommt immer mal wieder auf, ohne
allerdings genau zu sagen, was am bisherigen Wiki geändert werden
müsste. Sprich ist es das Aussehen der gerenderten Seite, irgend ein
bestimmtes Makro das fehlt, einfacheres Einbinden von Medien, …

Ralf

Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller, Gudrun Müller,
Nigel Vickers und Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Peter_Vratny-2 2009-08-21 16:42:35 UTC #10

rovilupa wrote:

du irrst: das Wiki kann gruppenspezifische und seitenbezogene Lese- und
Schreibrechte vergeben., wobei natürlich fraglich ist, wofür das gut sein
soll. Der Sinn eines Wiki ist ja gerade, dass alle zugreifen und vor allem
auch ändern können

Das war vielleicht einmal der ursprüngliche Gedanke hinter einem Wiki.

In einer Firmen-Umgebung macht es aber grossen Sinn, nicht jeden Content
allen zur Verfügung zu stellen bzw. unterschiedliche Gruppenrechte
vergeben zu können. Es spricht ja nichts dagegen auch vollkommen freie
Wiki-Teile zu pflegen, aber ein Wiki kann mehr sein.

Wir haben zB ein Wiki im Einsatz, dass viel mit Templates und Macros
arbeitet, dh Mitarbeiter/innen brauchen nur ein Formular ausfüllen um
Standard-Seiten zu erzeugen. Diese können dann auch Freitext
weiterbearbeitet werden. Die Templates und Macros selbst, die auch nur
als Wiki-Seiten vorliegen (moinmoin) können allerding nicht bearbeitet
werden.

Es gibt für den Support technische Dokumentation, auf die nur lesend
zugegriffen werden kann. Admins können diese Seiten auch ändern uswusf.
Es gibt mit Sicherheit Sinn von und Bedarf an Gruppenrechten. Ich ziehe
ein solches Wiki zB einer Lösung a la KnowledgBase bei weitem vor.

mfg
Peter

–
Have you tried to turn it off and on again?
http://klicklich.at

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Stefan_Roder 2009-08-21 20:32:56 UTC #11

Hallo Peter,
du hast Recht! Besser, es kann mehr, als das, was es mindestens können soll. In bestimmten Anwendungen oder Umfeldern macht eine Zugriffsbeschränkung absolut Sinn.
Gruss aus Hamburg
Stefan

Peter Vratny-2:

rovilupa wrote:

du irrst: das Wiki kann gruppenspezifische und seitenbezogene Lese- und
Schreibrechte vergeben., wobei natürlich fraglich ist, wofür das gut sein
soll. Der Sinn eines Wiki ist ja gerade, dass alle zugreifen und vor allem
auch ändern können

Das war vielleicht einmal der ursprüngliche Gedanke hinter einem Wiki.

In einer Firmen-Umgebung macht es aber grossen Sinn, nicht jeden Content
allen zur Verfügung zu stellen bzw. unterschiedliche Gruppenrechte
vergeben zu können. Es spricht ja nichts dagegen auch vollkommen freie
Wiki-Teile zu pflegen, aber ein Wiki kann mehr sein.

Wir haben zB ein Wiki im Einsatz, dass viel mit Templates und Macros
arbeitet, dh Mitarbeiter/innen brauchen nur ein Formular ausfüllen um
Standard-Seiten zu erzeugen. Diese können dann auch Freitext
weiterbearbeitet werden. Die Templates und Macros selbst, die auch nur
als Wiki-Seiten vorliegen (moinmoin) können allerding nicht bearbeitet
werden.

Es gibt für den Support technische Dokumentation, auf die nur lesend
zugegriffen werden kann. Admins können diese Seiten auch ändern uswusf.
Es gibt mit Sicherheit Sinn von und Bedarf an Gruppenrechten. Ich ziehe
ein solches Wiki zB einer Lösung a la KnowledgBase bei weitem vor.

mfg
Peter

–
Have you tried to turn it off and on again?
http://klicklich.at

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

PeterTandler 2009-09-16 15:37:21 UTC #12

Hallo Ralf,

ich suche gerade eine GW-Lösung, in der ich für verschiedene Projekte mit unterschiedlichen Partnern je ein eigenes Wiki nutzen kann. Soweit ich das bei egroupware gesehen habe, gibt es dort nur die Möglichkeit das wiki gemeinsam für alle User zu verwenden. Und es wird bestimmt nicht funktionieren, dass alle User immer die Zugriffsrechte pro neuer Seite selber auf die richtige Gruppe setzen.

Gibt es einen Trick, den ich übersehen habe?

Generell finde ich es auch wichtig, dass das wiki mit allen anderen Modulen sehr eng integriert ist: Ich möchte aus Projekt-Beschreibungen, Tracker- oder Info-Log-Items etc immer auf wiki-Seiten verweisen können (und umgekehrt). Es macht mE eh Sinn, dass (fast) alle Text-Infos intern als wiki-Seiten mit History abgelegt werden.

Kann ich aus dem wiki auf Dateien im Dateimanager verweisen?

Beste Grüße aus Darmstadt
Peter
www.teambits.de

Ralf_Becker_6 2009-09-16 16:23:33 UTC #13

Hi Peter,

PeterTandler schrieb:

Hallo Ralf,

ich suche gerade eine GW-Lösung, in der ich für verschiedene Projekte mit
unterschiedlichen Partnern je ein eigenes Wiki nutzen kann. Soweit ich das
bei egroupware gesehen habe, gibt es dort nur die Möglichkeit das wiki
gemeinsam für alle User zu verwenden. Und es wird bestimmt nicht
funktionieren, dass alle User immer die Zugriffsrechte pro neuer Seite
selber auf die richtige Gruppe setzen.

Man könnte natürlich eine Einstellung machen, sowas wie Gruppe und
Rechte für neue Seiten.

Gibt es einen Trick, den ich übersehen habe?

Generell finde ich es auch wichtig, dass das wiki mit allen anderen Modulen
sehr eng integriert ist: Ich möchte aus Projekt-Beschreibungen, Tracker-
oder Info-Log-Items etc immer auf wiki-Seiten verweisen können (und
umgekehrt). Es macht mE eh Sinn, dass (fast) alle Text-Infos intern als
wiki-Seiten mit History abgelegt werden.

Das Wiki was wir jetzt verwenden ist im Backend darauf ausgelegt, dass
es beliebig viele Wikis gibt. Es gibt dazu bisher aber keine GUI.

Wenn es nur um History geht, die bauen wir im Moment in fast alle
Anwendungen ein. Auch der Dateimanager wird in der nächsten
professionellen Version (EPL 9.2) Versionierung unterstützen.

Kann ich aus dem wiki auf Dateien im Dateimanager verweisen?

Klar vfs:/home/user/datei

Ralf

Beste Grüße aus Darmstadt
Peter
http://www.teambits.de www.teambits.de

ralfbecker wrote:

Die Diskussion nach einem Wiki Ersatz kommt immer mal wieder auf, ohne
allerdings genau zu sagen, was am bisherigen Wiki geändert werden
müsste. Sprich ist es das Aussehen der gerenderten Seite, irgend ein
bestimmtes Makro das fehlt, einfacheres Einbinden von Medien, …

–
Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller, Gudrun Müller,
Nigel Vickers und Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german