phpbar.de logo

Mailinglisten-Archive

[php] CMS

[php] CMS

Martin Kadlec php_(at)_phpcenter.de
Sat, 28 Apr 2001 15:08:45 +0200


Hi Björn,

> Nicht unbedingt korrekt. Von ActiveX-Schweinekram rede
> ich hier aber gar nicht. (WYSIWYG-Editoren gibt's auch
> schon mit JavaScript)

ActiveX hat sicherlich einen schlechten Ruf. Es handelt sich aber wie so oft
um eine Frage des richtigen Umgangs. Wir haben bei der Entwicklung darauf
geachtet, das ActiveX-Control so sparsam und vorsichtig wie möglich
einzusetzten. Schließlich kommt es an nur einer einzigen Stelle des CMS zum
Einsatz: im WYSIWYG-HTML-Editor. Wer nicht darauf steht und lieber
Plain-HTML im TEXTAREA bearbeiten möchte, kann das auch mit Xinity. Man
kommt mit ActiveX dann nicht mehr in Berührung.

Wieso sollte man aber beim Kochen auf Messer verzichten, nur weil man damit
auch Menschen umbringen kann? Man bedenke, dass es sich bei Xinity-Benutzern
um eine auf eine geschlossene, nichtöffentliche Benutzergruppe
zugeschnittene Applikaiton handelt, bei der obendrein die Quellen
offenliegen. Das verwendete ActiveX-Control HAT JEDER IE-Benutzer ab 5.0 auf
seinem System vorinstalliert. Man kann also durch Studium der Quelltexte
ausschließen, dass mit dem Control auch wirklich Schindluder getrieben wird.

Nimmt man schließlich die sonst bei geschlossenen Benutzergruppen und den
meisten kommerziellen CMS übliche Alternative der nativen
Windows-Anwenudung, so hat diese letztendlich auch vollständigen Zugriff auf
das System des Benutzers - zudem ist dann meistens keine Kontrolle des
Quelltextes möglich.

> Es geht bei CMSen meist nicht darum, ob das Produkt
> auf allen Plattformen (z.B. auch auf Opera) läuft, sondern
> dass es für die Leute, die es kaufen, benutzbar ist und die
> eigentliche Arbeit (nämlich die Website bauen zu können)
> erleichtert.

Genau dies war die Vorgabe. Wenn jemand Lust hat, statt 2x zu klicken lieben
10x zu klicken, nur um seinen Lieblingsbrowser benutzen zu können, bleibt
ihm diese Möglichkeit offen.

> Dass das CMS tatsächlich nur mit MSIE benutzbar ist,
> halte ich für unglücklich - ich persönlich würde ein
> normales TEXTAREA für die Eingabe der Seite zur
> Verfügung stellen, und bei Vorhandensein eines MSIE
> diese TEXTAREA gegen einen JS-driven WYSIWYG austauschen
> (lassen).

Wie gesagt, besteht diese Möglichkeit in Xinity auch. Allerdings ist
TEXTAREA natürlich eine Krücke sondersgleichen. Ich würde kein exzessives
Web-Authoring in Textarea-Feldern betreiben wollen. Aus diesem Grund wird
Xinity 1.1 eine Schnittstelle enthalten, mit der jeder seinen favorisierten
HTML/PHP-Editor benutzen kann. Schließlich denke man an CMS-Anwender, die
gar kein HTML beherrschen: entweder man setzt Ihnen fest kodierte
Eingabemasken vor die Nase (was in Xinity auch geht), oder man gibt Ihnen
eben einen WYSIWYG-Editor (mit konfigurierbaren Rechten).

Auch wäre ich Dir dankbar, wenn Du mir einen JS-Editor zeigen könntest, der
an den Komfort des Controls herankommt. Ich kann mir schon vorstellen, dass
so etwas theoretisch gehen könnte (Cursor ist ein blinkender Layer, über die
Klickkoordinaten und entsprechendes DOM-Parsing wird die neue Position
bestimmt usw.), die Frage ist, ob das dann auch benutzbar ist und wie hoch
der Aufwand ist, ihn an die DOMs von Netscape 4.7, 6 sowie Konqueror
anzupassen. Probieren kann mans ja mal... :)

Letztendlich verwendest Du ja in Deinem eigenen CMS ebenfalls jenes schöne
Control... sogar zur Darstellung von HTML-Quelltext ;)

Leider leider liegen auch beim Thema Applets Theorie und Praxis meilenweit
auseinander. Wir haben ein Java-Applet zur WYSIWYG-HTML-Bearbeitung
entwickelt. Eine eigene Engine zu schreiben ist allein aufgrund des raschen
Weiterentwicklung der Browser, zu aufwendig. Aber Sun hat ja schon etwas
vorarbeit geleistet und verspricht, in seinen HTML-SWING-Klassen HTML
3.2-Konformität. Leider hat es Sun bisher nicht annähenrd geschafft, CSS1
korrekt umzusetzten, ganz zu schweigen von den ganzen üblen Bugs und dem
katastophalen Klassenmodell, das der zuständige Entwickler Timothy Prinzing,
entworfen hat. Ein klassisches Beispiel, wie ein Konzept, das auf dem Papier
noch genial wirkt, in der Realität versagt.

Wie ich ebenfalls bereits erwähnt hab, wird Xinity 2.0 auf die
Zusammenarbeit mit verschiedenen Clients ermöglichen. Neben einem
browser-unabhängigen Mini-Client werden auch propritäre Clients für Windows
und wahrscheinlich auch auf Mozilla-Basis entwickelt (muss da noch etwas die
ZOPE-Entwicklung beobachten). Außerdem werden in Kürze die Quellen
veröffentlicht, so dass jeder, der Verbesserungsvorschläge hat, die auch
selbst einbringen können wird.


Mach's gut!

Ciao
Martin



php::bar PHP Wiki   -   Listenarchive