Hi!

Leider kann ich auf meine Space kein PEAR installieren. Da hab ich mir gedacht mach ich nen Ordner class und include eben nicht-Pear-Klassen.

Allerdings möchte ich auf meiner Seite Gebrauch von der Wiki Syntax machen, jedoch hab ich bis jetzt noch keine Wiki Syntax Parser Klasse im Web gefunden.

Als Template Engine wollte ich SmartTemplate benutzen. Db mäßig vielleicht adodb.

Hat jemand Ahnung wegen ner Wiki Klasse oder sonst irgendwelche nützlichen infos zu klassen?

Mister Ad

robo47

weis zwar nicht genau was mit ner wiki klasse gemeint ist, aber wenn sie mit wiki zu tun hat -> im wikisourcecode?

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Ich meine eine Parser Klasse, welche man mit Wikiformatierten Texten füttert und dann html ausgibt.

Basti

Was spricht dagegen, de PEAR-Klassen einfach per FTP auf deien Webspace zu ziehen (z.B. nach ./extern/pear/) und den include_path einfach im Skript anzupassen?

Auf der anderen Seite gibt es natürlich nicht DIE Wiki-Markup-Language, sondern es gibt in etwa so viele Wiki-Codes, wie es Wiki-Engines gibt. Dehalb würdich mal ein paar der unzäligen Aufzählungen von Wiki-Engines (z.B. [1]) abklappern und mich in den Sandkästen der einzelnen Wikis vergnügen, um mich dann entweder für eine zu entscheiden, deren Implementierung auch die Systemvoraussetzungen deiner Software trifft und deren Lizenzbedingungen du erfüllen kannst (und dann ist der Weg natürlich: Wiki runterladen und Klasse einfach übernehmen - für die API wirst du wohl keine Dokumentation brauchen) oder eben mir selbst eine Markup-Language entwerfen und dann nach einer Klasse suchen, die da möglichst nah dran kommt und diese dann anpassen.

[1] http://c2.com/cgi/wiki?WikiEngines

Basti

Hm...ja ich häng immer noch mit pear rum...ist vielleicht besser so. Ich werde da mal das mit PEAR nochmals versuchen. Allerdings funktioniert der go-pear.org installer nicht richtig, da safe-mode, etc. an ist da tauchen zig Fehler auf.

Das mit den Wiki Codes ist auch klar. Auf jedenfall find ich das besser zu handhaben als der BBcode in meinem content. Die texte sehen einfach klarer aus als mit diesen Tags noch drin. Was genau für eine wiki syntax ist eigentlich egal.

@bbastix
Wegen Pear. Funktioniert das auch ohne Installation? Einfach hochladen includen und fertig? Wenn ja in welchen Pfad soll ich pear pflanzen? meine Seite ist ja im /htdocs Ordner drin so etwa /htdocs/pear ? Dazu fällt mir noch ein das ich Zugriff auf einige Ordner unter htdocs habe wie etwa backup, restore, logs. Darunter ist auch ein leerer Ordner mit dem Namen Files. Den man per Web ja nicht aufrufen kann. Sollte da vielleich Pear rein?

Basti

Ja, fast. Die einzelnen PEAR-Klassen binden ihrerseits wiederum PEAR-Klassen ein, z.B. via require_once 'PEAR.php'; Diese Datei(en) würden jetzt im gleichen Vereichnis gesucht, in dem auch das Skript liegt, das der Benuzer aufgerufen hat bzw. in dn Ordnern, die im "include_path" definiert wurden. Da werden diese Dateien aber wahrscheinlich nicht liegen.

Der include_path ist in der php.ini definiert, die du ja aber bei dem Provider nicht ändern kannst (mutmaße ich mal). Daher musst du diesen Wert aus dem Skript heraus via ini_set() ändern:

Du liest also mit ini_get() den Wert von include_path aus und hängst nach einem Semikolon den neune Pfad einfach hintendran. Der Wert gilt dann für dieses Skript, überschreibt also nicht etwa die globale Konfigurationsdatei.

Prinzipiell ist es geschickt, die ganze Anwendung quasi zu versenken, so dass nur z.B. ein Front-Controller (index.php) und ein Ordner mit den via HTTP einzubindenden Dateien (Bilder, externe CSS- und JS-Files etc.), sowie Dateien, die du zum Download anbietest und ggf. deine gecachten Seiten, also eingefrorene, statische Abbilder (HTML-Code) der dynamisch erzeugten Seiten in deinem Documet Root liegen.

Es hört sich allerdings so an, als könntest du den Document Root be deinem Prvider garnicht frei (je Domain) wählen, daher legst du halt deine ganze Anwendung in ein Unterverzeichnis und schützt dieses mit HTTP_Basic_Authentication (mit eine .htaccess-Datei). Letztlich ist es Wursct, ob man deine Pear-Klasse über das Web ereichen kann, aber wenn du die ganze Anwendung über HTTP unzugänglich machst, ersparst du dir das explizite "Wegversperren" zu allen sicherheitsrelevanten Dateien.

Und, wie du das Verzeichnis nennst ist letztlich Wurscht. Wenn du nur eine Anwendung laufen hast oder diese auch weitergeben möchtest, würde ich ei Verzeichnis ./external/pear oderal anlegen, oder ./inc/extern/pear oder auch ./opt/pear. Benutzt du mehrere Anwendungen in deinem Webspace, dann würde ich eher in das Basis-Verzeicnis deines Webspace einen Ordner ./pear und eine .hacces legen, die den Include-Path für den geammten Webspace um dieses PEAR-Verzeichnis erweitert.

Basti

Nich gleich mit Kanonen auf Spatzen schießen:
Damit ist die Sache gegessen.